Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I agree with you that the code is pretty readable, and well-commented. But in my experience with the code-bases of MRI (Ruby), CPython, and Lua, IMO CPython is by far the hairiest.

Here is what I mean by "hairy": reading the Python source, you see all sorts of complexity that looks like it is the result of patching problems in previous versions. There are all sorts of comments of the form "we have to do this weird thing here because some obscure things breaks if we don't." The most extreme example of this I've seen is this monster comment, written in the style of a FAQ because it's so complicated:

https://hg.python.org/cpython/file/9beeb4c1375d/Objects/type...

I've had so many experiences of wondering "wtf is Python doing, I don't get it," only to find some strange behavior in the interpreter that I never could have anticipated. Things like this won't affect most people writing straight Python, but once you are writing C extensions the inner complexity of CPython becomes far more apparent.

Here is an example of a problem I ran into. I had a C extension that was working fine in Python 2.x and 3.3, but then I got bug reports from my users that it was broken in 3.4. It turned out Python 3.4 had added a restriction: it was no longer allowed to make a statically-allocated type derive from a dynamically-allocated type. Why the new restriction? It's not entirely clear: this rule isn't documented anywhere, and the bug/change that added the restriction has no explanation (http://bugs.python.org/issue22079). They probably discovered some scenario where allowing this could lead to problems, so they added some code to disallow it.

This is my experience working with CPython. Lots of subtle rules and semantics, many of which are not documented except as comments in the source.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: