Hacker News Reader

> This post is surprisingly confused, it is phrased as a complaint about the language, then immediately degrades into CPython implementation-specifics that have little bearing on the actual usability of the language itself.

You might think that, but you are very wrong and I should probably make that point in another blog post. These CPython specifics are enshrined in the language. While PyPy does not have the actual structs, it needs to implement the same user exposed API as it slots were used.

PyPy cannot just say "a + b" means "a.__add__(b)", it needs to implement the exact same dispatch logic that CPython has because people's code depends on it.

//EDIT:

> Ronacher seems to be advocating that we should punish the CPython implementation's traditional strong areas in favour of.. actually, he didn't even describe any vision that was impacted by his complaints.

Maybe I did not make my point very clear but the whole last paragraph advocates about trying a version of Python that abolishes the internal slot system.

Once again, this sounds like a bug report, not a ranty blog post

And what exactly should the bug report be? "I do not agree with design decision made 25 years ago, please make backwards incompatible change?".

The first might be "Let's replace all use of tp_* with hash lookups", which I suppose would be closed quickly, amidst a storm of muffled giggles. But at least by then you'd know why the current implementation works the way it does.

The next might be "__getattribute__ mechanism has surprising behaviour in common use-case" (which itself would imply having a use case where any of this mattered). This one might actually result in some productive discussion regarding a fix.

Your second reply is basically a doc bug, one of "__getattribute__ optimization is not specified in the language reference" or "__getattribute__ optimization causes non-comformance with the language specification", either way, you would get the attention of the few people who can actually help you, rather than attention from the many more who can't

You're assuming I am not aware why the system works the way it does currently which is incorrect. I outlined what a Python could look like, not what I want the CPython guys to implement. I am perfectly aware that this is not going to happen.

I think if you had titled the post differently you would have ended up with a lot less argumentation about how what you propose isn't a good idea for python.

As it is, the title at least primes the reader to think you are asking for what you go on to describe.

Ok, what is the bug report? Can you post the bug report as you'd write from your perspective.

>This post is surprisingly confused, it is phrased as a complaint about the language, then immediately degrades into CPython implementation-specifics that have little bearing on the actual usability of the language itself.

Ronacher says: "Python is definitely a language that is not perfect. However I think what frustrates me about the language are largely problems that have to do with tiny details in the interpreter and less the language itself. These interpreter details however are becoming part of the language and this is why they are important."

He is right, Python has not real standard with clearly defined semantics. Actually, the standard is CPython, but CPython is full of crap that other implementations are then forced to implement thus making that crap part of the language. You should avoid Python at any cost, into the trash it goes.

Your logic does not follow. "There is a problem affecting how implementors have to implement a language, so therefore the language has no use and everybody should just go home" is silly and hyperbolic. From an end-users perspective, Python is still a very useful language. Sure, it has some idiosyncrasies, but that doesn't make it "crap".

His complaint is that implementation details of the interpreter have leaked into the specification of the language, such as it exists. The result is that alternate implementations have to mimic those quirks of the interpreter in order to achieve compatibility.

Having an abstract specification of the language, rather than "whatever CPython does", would give implementors more freedom, and thus allow the use of Python in more places and circumstances.