LWN: Comments on "Reports from the 2021 Python Language Summit" https://lwn.net/Articles/857490/ This is a special feed containing comments posted to the individual LWN article titled "Reports from the 2021 Python Language Summit". en-us Sat, 04 Oct 2025 10:01:32 +0000 Sat, 04 Oct 2025 10:01:32 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Reports from the 2021 Python Language Summit https://lwn.net/Articles/860071/ https://lwn.net/Articles/860071/ massimiliano <p> Tagged pointers are not GC-specific, they are a clever hack to make the "tagged union type" "pointer OR integer" extremely compact and efficient, at the cost of losing one bit from the integer. </p> <p> They are used extensively in V8 (I worked on that codebase), and the GC cares about them only to discriminate pointers from integers (which is part of the "union type" semantics anyway: the GC would need to care about it regardless of the union type representation). </p> <p> Perhaps the speedup in Python is less significant because in cpython there are other bottlenecks at work, <i>including</i> reference counting... </p> Thu, 17 Jun 2021 07:01:19 +0000 Reports from the 2021 Python Language Summit https://lwn.net/Articles/857688/ https://lwn.net/Articles/857688/ Cyberax <div class="FormattedComment"> Python became a staple in the AI community and people are seriously getting allergic to usual nonsense of: &quot;rewrite performance-critical parts in C&quot; and &quot;nobody needs multithreading&quot;.<br> </div> Mon, 31 May 2021 08:08:06 +0000 Reports from the 2021 Python Language Summit https://lwn.net/Articles/857686/ https://lwn.net/Articles/857686/ anton Once upon a time there was a project called Unladen Swallow for speeding up CPython. It was sponsored by Google, but Google lost interest, and the project was stopped. Why was it not picked up at the time, i.e., why was interest in CPython speed low a decade ago and what causes the renewed interest in CPython speed? Mon, 31 May 2021 08:04:51 +0000 Reports from the 2021 Python Language Summit https://lwn.net/Articles/857607/ https://lwn.net/Articles/857607/ pbonzini <div class="FormattedComment"> Maybe it&#x27;s more suited to GC runtimes than to reference counting?<br> </div> Fri, 28 May 2021 18:51:51 +0000 Reports from the 2021 Python Language Summit https://lwn.net/Articles/857517/ https://lwn.net/Articles/857517/ vstinner <div class="FormattedComment"> I&#x27;m working on hiding implementation details from the C API in CPython: <a href="https://www.python.org/dev/peps/pep-0620/">https://www.python.org/dev/peps/pep-0620/</a><br> <p> I wrote a proof-of-concept tagged pointer PR. It is 1.1x slower on average: <a href="https://github.com/vstinner/cpython/pull/6">https://github.com/vstinner/cpython/pull/6</a> But my implementation only supports numbers in [-5; 256] range which is quite limited :-) I didn&#x27;t write my PR to check performance, but to prove that such experimentation is easier if my PEP is implemented (it&#x27;s already partially implemented).<br> <p> PyPy tried tagged pointers and it wasn&#x27;t way more efficient for Python: <a href="https://doc.pypy.org/en/latest/config/translation.taggedpointers.html">https://doc.pypy.org/en/latest/config/translation.taggedp...</a><br> </div> Thu, 27 May 2021 23:32:46 +0000 Reports from the 2021 Python Language Summit https://lwn.net/Articles/857498/ https://lwn.net/Articles/857498/ pbonzini <div class="FormattedComment"> The decision not to use tagged pointers for 31- or 63-bit integers in Python has always baffled me. Unfortunately it&#x27;s baked in the C extension API.<br> </div> Thu, 27 May 2021 17:54:45 +0000