4 ms·

This post is surprisingly confused, it is phrased as a complaint about the language, then immediately degrades into CPython implementation specifics that have l

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 usability of the language itself. Ronacher should also know better than to post microbenchmarks like the one provided here, especially without corresponding (C) profiler output. At the C level, slots allow the implementation constant-time access to the most common code paths for an object, and especially when you have C code calling other C code via the type system (IMHO the primary use for Python, and still its strongest use case), "interpreter overhead" is reduced to a few extra memory indirection operations. In the alternative world, sure, perhaps some microbenchmark may behave faster, but now systemically, and for e.g. "reduce(operator.add, range(1000))" requires more hash table lookups than I can count. Python is all about providing a lightweight way to compose bits of fast code (the kernel, network stack, NumPy, MySQL, whatever). Unfortunately somewhere along the way solutions like Django got popular, which are almost the antithesis to this old viewpoint. 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. He just seems to want the CPython implementation to suffer. Perhaps his complaint about new-style __getattribute__ would be better suited as a bug report, it seems the only substantial observation made about the language itself in this post.

the_mitsuhiko 12y ago
> 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.
- hosay123 12y ago
  Once again, this sounds like a bug report, not a ranty blog post
  - the_mitsuhiko 12y ago
    And what exactly should the bug report be? "I do not agree with design decision made 25 years ago, please make backwards incompatible change?".
    - hosay123 12y ago
      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
      - the_mitsuhiko 12y ago
        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.
        maxerickson 12y ago
        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.
topkekz 12y ago
>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.
- SoftwareMaven 12y ago
  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".
cwp 12y ago
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.

the_mitsuhiko 12y ago

> 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.

hosay123 12y ago
Once again, this sounds like a bug report, not a ranty blog post
- the_mitsuhiko 12y ago
  And what exactly should the bug report be? "I do not agree with design decision made 25 years ago, please make backwards incompatible change?".
  - hosay123 12y ago
    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
    - the_mitsuhiko 12y ago
      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.
      - maxerickson 12y ago
        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.

topkekz 12y ago

>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.

SoftwareMaven 12y ago
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".

cwp 12y ago

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.