The discussion centers on the death of Python contributor Tim Peters, with widespread tributes to his technical legacy like Timsort and the Zen of Python clashing with heated disagreements over his controversial suspension by the Python Software Foundation. While many users urge focusing solely on his contributions, others argue that ignoring the PSF's handling of his ban is a disservice to his memory and an endorsement of flawed community governance.
189 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4python
cpython
Python2014–2026
python / cpython
cpython
The Python programming language
400Distinct people
547Mentions
3Explicit recommenders
78.2KGitHub stars
What to know before exploring
What it is
The Python programming language
GitHub
Where it is used
- AWS Lambda — AWS Lambda provides a managed runtime and container base image for Python 3.11 that runs on CPython’s interpreter improvements. It uses CPython’s specialization adaptive interpreter features to improve Lambda workloads’ performance. Source
- abridging clinical conversations using python — “In addition to the above-mentioned instances, we also use Python widely in conjunction with several Google Cloud Platform (GCP) services and to set up other monitoring and debugging tools.” Source
- 4 more documented examples
What people are saying
I love the description in the draft PR: 'Twas the night before Christmas, when all through the code Not a core dev was merging, not even Guido; The CI was spun on the PRs with…
divbzero used a recommendation phrase. 3 indexed comments match. This is a phrase match, not a verdict.
Favorable Commenters discuss Tim Peters' contributions to CPython, including int-to-str conversion and Timsort. The tone is respectful and appreciative of his technical achievements.
This week’s discussion is favorable. This is not a standing endorsement. Read the supporting reply
Also in these discussions
- golang/go · linked in 2 of the same discussions
- nodejs/node · linked in 2 of the same discussions
- ruby/ruby · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Favorable
Commenters discuss Tim Peters' contributions to CPython, including int-to-str conversion and Timsort. The tone is respectful and appreciative of his technical achievements.
Supporting reply 1 · Supporting reply 2 · 2 discussions summarized
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
Read the discussion on HN. A full-thread summary is not available yet.
Read the discussion on HN. A full-thread summary is not available yet.
Showing the three threads with the most distinct people linking this repo, from 5 threads this week.
Mentions over time
HN mentions by year547 dated mentions
Observed mentions: 2014-12-30 12:04:55 UTC to 2026-10-27 17:34:51 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 20 | 2 | 18 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 36 | 4 | 32 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 28 | 2 | 26 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 33 | 4 | 29 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 54 | 2 | 52 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 62 | 3 | 59 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 63 | 6 | 57 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 64 | 4 | 60 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 70 | 6 | 64 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 72 | 6 | 66 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 40 | 5 | 35 |
What Hacker News says
36 sourcesMAmarviel·Nov 27, 2017Submission
1 points · Open discussionOne thing that was really educational for me was reading how CPython implemented their object system. https://github.com/python/cpython/blob/master/Include/object...
Basically objects are structs that all share the same header which contains a pointer to the object type (ob_type) and the reference count (ob_refcnt) for memory management.
That way you can always cast back to a pointer of that header struct and access ob_type and ob_refcnt no matter what the actual implemented struct contains afterwards.
ob_type contains the name of the type and function pointers for common methods used by objects (getattr, setattr, hash, arithmetic, etc).
In Object oriented programming with ANSI-C (1993) [pdf]This myth is even in Python source code[1]
However, since the indirect jump instruction is shared
by all opcodes, the CPU will have a hard time making
the right prediction for where to jump next (actually,
it will be always wrong except in the uncommon case of
a sequence of several identical opcodes).
[1] https://github.com/python/cpython/blob/ff8ad0a576c6cf375e682...
In Are Jump Tables Always Fastest?You're actually wrong about Python's sum function, it works for anything you can + on BUT strings [0], this is to avoid quadratic behavior with string concatenation.
[0] https://github.com/python/cpython/blob/5837d0418f47933b2e3c1...
In Haskell People> Go and Rust expose UTF-8 at the byte level. This is something of a headache and may result in invalid string slices.
Rust will panic on invalid slices unless you first convert to raw bytes, and then it will not allow converting invalid slices back to a string in safe rust (in unsafe you're obviously on your own).
Safe Rust guarantees and requires[0] that strings are valid UTF8 at all times.
That aside, essentially all of your desires are part of Swift's string, you should check them out.
> Requests for s[0] to s[N], and s[-1] to s[-N], for small N, should be handled by working forwards or backwards through the UTF-8. (Yes, you can back up by rune in UTF-8. That's one of the neat features of the representation.)
Rust does that through the `chars()` iterator[1] which iterates through USVs (codepoints) and can be iterated from both ends. S
Read the rest
adly unlike Swift it does not ship with a grapheme cluster iterator. Happily there is a unicode_segmentation crate[2]. Swift also uses iterators but has more of them: the default iteration works on extended grapheme clusters, and alternate iterators are USV, UTF-16 and UTF-8.
If indexing is necessary for some reason Rust also has char_indices() which iterates on the USV and its (byte) position in the string.
> - Lookup functions such as "index" should return an opaque type which represents the position into that string. If such an object is used as a subscript, there's no need to build the index by rune. If you coerce this opaque type into an integer, the index table has to be built. Adding or subtracting small integers from this opaque type should be supported by working backwards or forwards in the string.
That is what Swift does. `String.index(of:String)` will return a String.Index: https://developer.apple.com/documentation/swift/string.index and indexed String methods will work based on that index type. This includes "reindexing" (offsetting) which is done using String.index(String.Index, offsetBy: String.IndexDistance). Furthermore String exposes two built-in indexes startIndex and endIndex as well as an "indices" iterator.
> This would maintain Python's existing semantics while reducing memory consumption.
It would not maintain O(1) USV indexing (especially in the C API), which was the reason for not just switching to UTF8.
In fact, FSR strings already contain a full UTF8 representation of the string[3], which the latin1 representation can share for pure ASCII strings.
[0] a non-utf8 str is one of Rust's 10 undefined behaviours, part of the "invalid primitive values" section alongside null references or invalid booleans: https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html
[1] https://doc.rust-lang.org/std/primitive.str.html#method.char...
[2] https://kbknapp.github.io/clap-rs/unicode_segmentation/index...
[3] https://github.com/python/cpython/blob/49b2734bf12dc1cda80fd...
In my original comment I wrote "'namedtuple' has one good use - migration from a tuple object to a real object while allowing backwards compatability to the tuple API. For example, the old tuples once returned from os.stat() and time.gmtime()."
The two examples you gave are examples of that good use.
The time.localtime() used to return a tuple. See https://github.com/python/cpython/blob/770e4042db8a1c277b5d9... . The change to StructTimeType is an example of how to do that sort of migration.
Similarly, sys.version_info() used to return a tuple. See https://github.com/python/cpython/blob/193a3f6d37c1440b049f7... . Again, a good example of how to migrate.
However, the "this" in the "There is no reason for this to expose a tuple API" which you quoted refers specifically to the namedtuple that cache_info() returns. That did not replace a tup
Read the rest
le, it replaced two attributes, as you can see at https://github.com/python/cpython/commit/234515afe594e5f9ca1... .
And returning a simple type with a couple of attributes while also (and needlessly) treating it as a tuple was never a norm in Python before namedtuples, if only because it was a lot of work.
You are correct, and I apologize for not looking into this more deeply first.
For the specific case under discussion, ncoghlan added cache_info() on 30 Nov 2010 - https://github.com/python/cpython/commit/234515afe594e5f9ca1...
Previously, "Performance statistics stored in f.cache_hits and f.cache_misses." With the change "Significant statistics (maxsize, size, hits, misses) are available through the f.cache_info() named tuple."
There was no time when it was a tuple, much less in a tuple in a public release.
I'll look first at the namedtuples which have been present since at least 2.7.10.
The named tuples in "urllib/parse", "difflib", "inspect", "sched", and "doctest" were originally tuples. The decimal module's uses a DecimalTuple as a return value from to_tuple(), so I didn't check that history.
ssl uses a DefaultVerifyPaths added by tir
Read the rest
an on 9 Jun 2013 - https://github.com/python/cpython/commit/6d7ad13a458afdf2cbd... . It did not replace a tuple. I assume _ASN1Object is the same way.
Now for the namedtuples in recent version control:
dis.py:_Instruction was added in https://github.com/python/cpython/commit/b39fd0c9b8dc6683924... . It did not replace a tuple.
aifc.py:_aifc_params replaces a tuple.
crypt.py:_Method replaced a class with a namedtuple in https://github.com/python/cpython/commit/daa5799cb8866785543... .
nntplib.py:GroupInfo and ArticleInfo added in https://github.com/python/cpython/commit/69ab95105f5105b8337... . It did not replace a tuple.
pkgutil.py:ModuleInfo replaces a tuple
platform.py:uname_result replaces a tuple
sndhdr.py:SndHeader replaces a tuple
sunau.py:_sunau_params replaces a tuple
tokenize.py:TokenInfo replaces a tuple
typing.py:nm_tpl ... is above my paygrade to understand. I believe it's required to be a namedtuple since that what it's trying to implement.
wave.py:_wave_params replaces a tuple.
Finally, urllib/robotparser.py appears to contain a bug in the following:
req_rate = collections.namedtuple('req_rate',
'requests seconds')
entry.req_rate = req_rate
entry.req_rate.requests = int(numbers[0])
entry.req_rate.seconds = int(numbers[1])
As I read it, this should fail as the req_rate is immutable. This appears to be written by someone who thinks that it's a lightweight object. The commit is https://github.com/python/cpython/commit/960e848f0d32399824d... . It did not replace a tuple.
In conclusion, 8 of the current uses of namedtuple are not to emulate a tuple. 13 of the current uses replace a tuple.
I did some git archaeology. Here are relevant commits and bug reports:
* Initial commit with -1...99 cached:
https://github.com/python/cpython/commit/842d2ccdcd540399501...
* Cache more negative numbers, -5...99:
https://github.com/python/cpython/commit/c91ed400e053dc9f11d...
https://bugs.python.org/issue561244
* Cache more positive numbers, -5...256:
https://github.com/python/cpython/commit/418a1ef0895e826c65d...
https://bugs.python.org/issue1436243
In Weird Python IntegersYeah, the stdlib bz2 module does release the GIL for the time of the compression (though it locks the compressor object simultaneously): https://github.com/python/cpython/blob/d4b93e21c2664d6a78e06...
In Let's Remove the Global Interpreter LockArgparse's source is possibly the most difficult lib to grow from the stdlib. https://github.com/python/cpython/blob/master/Lib/argparse.p...
For me, it is not debugable. I wanted to propose and start a reference implementation for supporting --[no-]bool-opt, but I quickly gave up. There's some solutions on SO, but none of them are sufficient. The best solution makes --bool-opt mutually exclusive to --no-bool-opt which will cause a hard failure which is not okay for shell aliases.
In Python Entry Points ExplainedC99 took a while to be widely adopted mainly because some compilers where very slow on the uptake (I'm looking at you Visual C++) but now I would never consider using anything less than that for a new project. It's almost 20 years old!
Many small quality of life improvements: stdint.h stdbool.h, inline, restrict, allowing variable declaration within the code, snprintf, variadic macros...
Most of those were accessible through compiler extensions but having them in the standard means that you know it'll work everywhere on any compliant implementation.
Linux definitely isn't conservative when it comes to the language, not only does it use modern features of the language but it even relies on GCC extensions and even sometimes on the compiler's optimizer to produce the correct code: https://unix.stackexchange.com/questions/153788/linux-cannot
Read the rest
...
I'm not super familiar with CPython but it also doesn't appear to limit itself to C89, see for instance this random file I opened: https://github.com/python/cpython/blob/master/Python/future....
You can see that `const char *feature` is declared in the middle of some code. It also uses "inline" in several places.
I was looking through the source and learned that Python's modulo operator is based on floor-division (rather than round-toward-0 division like in C). In case anyone cares how Python actually does in in C, for small ints its defined at https://github.com/python/cpython/blob/master/Objects/longob...
In Block-breaking game in vim 8.0Python has migrated from hg to git. The current version of tupleobject.c is here:
https://github.com/python/cpython/blob/master/Objects/tupleo...
In Diving into the world of hash tablesShowing the 15 most recent of 36 sources. Enable JavaScript to search and browse every indexed mention.