5 ms·

Don't understand why you are being downvoted, coming from another language, it's an understandable surprise. The explanation is that Python features heavy dyna

Don't understand why you are being downvoted, coming from another language, it's an understandable surprise. The explanation is that Python features heavy dynamism, meaning one can easily replace any part of the system at runtime (at any moment), including builtins, code objects, and even hook into the parser, AST, import mechanism, etc. This renders inlining a dangerous exercice: say you inline the builtin len() function, how do you know it's not the intent of a code that runs later to replace it with a different implementation? Now, there are ways to implement inlining, but they are not as straightforward as say, with a compiler, when you know nothing is going to change afterward. So it's something that had be delayed.

SemanticStrengh 4y ago
> how do you know it's not the intent of a code that runs later to replace it with a different implementation? I think progress could move forward by adding a compiler flag "assume no fully free function body replacement" you know just like in every other mainstream language.
- BiteCode_dev 4y ago
  It's not body replacement, it's function reference erasing. There is no way in Python to tell something has been replaced or not, since variables are dumb labels and a reference is the same kind for any object. In fact, there is no particular difference between 2 objects in python. E.G: functions are objects, and any object can be called as a function. And it's just a reference to "something callable" in the namespace mapping (literally a dict in most implementations), which is mutable by definition Also a compiler flag would not help, since most users don't compile the python VM. Now, you could put a runtime flag, that list all stuff that are created for the first time in a namespace, and refuse to allow reassignment. It's possible, but it would break a LOT of things and prevent many patterns. The last attempt was to put guards, and to assume no replacement, but if a replacement occurs, then at this moment we revert locally this assumption. The process is refined at each iteration, but there is no turn-key solution as you seem to believe.
- masklinn 4y ago
  > I think progress could move forward by adding a compiler flag "assume no fully free function body replacement" you know just like in every other mainstream language. Ah yes, a compiler flag which literally says “break the language”, that sounds like a great feature which would be used a lot. > assume no fully free function body replacement There is no “body replacement”, the `len` builtin is looked up as a global in the module on every access, anyone can just replace the module’s global.
  - SemanticStrengh 4y ago
    I'm just advocating for a compiler flag that says "do_reasonable things" just like in every other mainstream language. Python must free himself from those idiosyncrasies if it wants to stay relevant, migrations are not that hard especially since those patterns seems illegitimate or workaroundable (e.g. use overriding if you want to replace a function or do extension methods). At worst at least tag the concerned functions as dirty via an annotation which will tell cpython to locally deoptimize. I'm not arguing for an exceptional thing, just for conventionality and sanity.
    - adrianN 4y ago
      > migrations are not that hard You might recall that there are still holdouts who haven't migrated to Python 3. Breaking changes are generally not a good idea in mature languages.
      - misnome 4y ago
        One of our scientific collaborators is _literally_ of the view that "One day people will realise what a mistake python 3 was, and go back to Python 2" (which is a verbatim quote).
        cesarb 4y ago
        While this has happened with Perl (AFAIK, people realized what a mistake Perl 6 was, and there's a plan for Perl 7 to mostly go back to Perl 5, which makes it two breaking changes in a row), I see no signs of it happening with Python; instead, every new Python 3 release gets farther from Python 2.
Aardwolf 4y ago
> The explanation is that Python features heavy dynamism JavaScript too, any function can be dynamically changed at any time, but its function calls are 30x faster (roughly, I measured it just now with a for loop doing 100 million function calls, which took 0.5s in JS, 15s in python) This is a realistic scenario if you want to run e.g. a custom statistics function on a large array in python so it can be annoying (and yes numpy can do things but that's no reason to keep the main language encouraging less readable code where you don't define separate functions)
- BiteCode_dev 4y ago
  Hence the "So it's something that had be delayed.", and not "this is something impossible". Javascript has the benefit of having billions of dollars allocated to it from Google/Microsoft/Apple to hire dozen of amazing engineers full time over decades to work on it. Python has existed since 1994, yet in 2011, the Python Software Fundation budget was less than $40K: https://pyfound.blogspot.com/2012/01/psf-grants-over-37000-to-python.html https://pyfound.blogspot.com/2012/01/psf-grants-over-37000-t... We are talking a difference of funding of 6 order of magnitudes. Not to mention one is a language that has to stand on its own, the second has an accidental monopoly on the most popular plateform in the world. So it had to be delayed, unlike for JS.
  - SemanticStrengh 4y ago
    > Python has existed since 1994, yet in 2011, the Python Software Fundation budget was less than $40K Exact, as usual it is mainly a question of human resources. Hence why I advocate for Python switching to GraalPython as the default runtime, it would enable much better performance in the next few years. Also, I'm pretty sure cpython devs should ask Google/OpenAI/MicrosoftAI funding, how many millions can they waste on useless projects while not improving the core bottleneck..
    - BiteCode_dev 4y ago
      You are asking for the rarest thing of all, a geek and volounteer worker that is also good at dealing with big entities and comfortable with managing money.

SemanticStrengh 4y ago

> how do you know it's not the intent of a code that runs later to replace it with a different implementation? I think progress could move forward by adding a compiler flag "assume no fully free function body replacement" you know just like in every other mainstream language.

BiteCode_dev 4y ago
It's not body replacement, it's function reference erasing. There is no way in Python to tell something has been replaced or not, since variables are dumb labels and a reference is the same kind for any object. In fact, there is no particular difference between 2 objects in python. E.G: functions are objects, and any object can be called as a function. And it's just a reference to "something callable" in the namespace mapping (literally a dict in most implementations), which is mutable by definition Also a compiler flag would not help, since most users don't compile the python VM. Now, you could put a runtime flag, that list all stuff that are created for the first time in a namespace, and refuse to allow reassignment. It's possible, but it would break a LOT of things and prevent many patterns. The last attempt was to put guards, and to assume no replacement, but if a replacement occurs, then at this moment we revert locally this assumption. The process is refined at each iteration, but there is no turn-key solution as you seem to believe.
masklinn 4y ago
> I think progress could move forward by adding a compiler flag "assume no fully free function body replacement" you know just like in every other mainstream language. Ah yes, a compiler flag which literally says “break the language”, that sounds like a great feature which would be used a lot. > assume no fully free function body replacement There is no “body replacement”, the `len` builtin is looked up as a global in the module on every access, anyone can just replace the module’s global.
- SemanticStrengh 4y ago
  I'm just advocating for a compiler flag that says "do_reasonable things" just like in every other mainstream language. Python must free himself from those idiosyncrasies if it wants to stay relevant, migrations are not that hard especially since those patterns seems illegitimate or workaroundable (e.g. use overriding if you want to replace a function or do extension methods). At worst at least tag the concerned functions as dirty via an annotation which will tell cpython to locally deoptimize. I'm not arguing for an exceptional thing, just for conventionality and sanity.
  - adrianN 4y ago
    > migrations are not that hard You might recall that there are still holdouts who haven't migrated to Python 3. Breaking changes are generally not a good idea in mature languages.
    - misnome 4y ago
      One of our scientific collaborators is _literally_ of the view that "One day people will realise what a mistake python 3 was, and go back to Python 2" (which is a verbatim quote).
      - cesarb 4y ago
        While this has happened with Perl (AFAIK, people realized what a mistake Perl 6 was, and there's a plan for Perl 7 to mostly go back to Perl 5, which makes it two breaking changes in a row), I see no signs of it happening with Python; instead, every new Python 3 release gets farther from Python 2.

Aardwolf 4y ago

> The explanation is that Python features heavy dynamism JavaScript too, any function can be dynamically changed at any time, but its function calls are 30x faster (roughly, I measured it just now with a for loop doing 100 million function calls, which took 0.5s in JS, 15s in python) This is a realistic scenario if you want to run e.g. a custom statistics function on a large array in python so it can be annoying (and yes numpy can do things but that's no reason to keep the main language encouraging less readable code where you don't define separate functions)

BiteCode_dev 4y ago
Hence the "So it's something that had be delayed.", and not "this is something impossible". Javascript has the benefit of having billions of dollars allocated to it from Google/Microsoft/Apple to hire dozen of amazing engineers full time over decades to work on it. Python has existed since 1994, yet in 2011, the Python Software Fundation budget was less than $40K: https://pyfound.blogspot.com/2012/01/psf-grants-over-37000-to-python.html https://pyfound.blogspot.com/2012/01/psf-grants-over-37000-t... We are talking a difference of funding of 6 order of magnitudes. Not to mention one is a language that has to stand on its own, the second has an accidental monopoly on the most popular plateform in the world. So it had to be delayed, unlike for JS.
- SemanticStrengh 4y ago
  > Python has existed since 1994, yet in 2011, the Python Software Fundation budget was less than $40K Exact, as usual it is mainly a question of human resources. Hence why I advocate for Python switching to GraalPython as the default runtime, it would enable much better performance in the next few years. Also, I'm pretty sure cpython devs should ask Google/OpenAI/MicrosoftAI funding, how many millions can they waste on useless projects while not improving the core bottleneck..
  - BiteCode_dev 4y ago
    You are asking for the rarest thing of all, a geek and volounteer worker that is also good at dealing with big entities and comfortable with managing money.