6 ms·

> 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

> 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.
        mattkrause 4y ago
        I thought the Perl situation was a little more nuanced. Although Perl 6 was meant to be a Python 3000 type thing, it was spun out into its own language (Raku). Perl 7 will continue the 5.x lineage, but with saner defaults. Thus, any code that’s around now should run, but the interpreter’s name might change. (I think…I mostly keep up with Perl for nostalgia’s sake).
        cesarb 4y ago
        > Although Perl 6 was meant to be a Python 3000 type thing, it was spun out into its own language (Raku). The problem for them is that Perl 6 actually had an official release (and IIRC, more than one) under the Perl 6 name; the rename of the language to Raku (which IIRC was originally the name of just one VM for running Perl 6 programs) came later. So anyone who managed to keep up with the latest release of the Perl language would have two huge breaking changes (Perl 5 to Perl 6 and Perl 6 to Perl 7), the second one undoing most of the changes of the first. (AFAIK, PHP avoided all that by deciding to go back before officially releasing PHP 6, so anyone who was following the latest release just jumped directly from PHP 5 to PHP 7, avoiding the breaking changes which had been planned for PHP 6.)

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.
      - mattkrause 4y ago
        I thought the Perl situation was a little more nuanced. Although Perl 6 was meant to be a Python 3000 type thing, it was spun out into its own language (Raku). Perl 7 will continue the 5.x lineage, but with saner defaults. Thus, any code that’s around now should run, but the interpreter’s name might change. (I think…I mostly keep up with Perl for nostalgia’s sake).
        cesarb 4y ago
        > Although Perl 6 was meant to be a Python 3000 type thing, it was spun out into its own language (Raku). The problem for them is that Perl 6 actually had an official release (and IIRC, more than one) under the Perl 6 name; the rename of the language to Raku (which IIRC was originally the name of just one VM for running Perl 6 programs) came later. So anyone who managed to keep up with the latest release of the Perl language would have two huge breaking changes (Perl 5 to Perl 6 and Perl 6 to Perl 7), the second one undoing most of the changes of the first. (AFAIK, PHP avoided all that by deciding to go back before officially releasing PHP 6, so anyone who was following the latest release just jumped directly from PHP 5 to PHP 7, avoiding the breaking changes which had been planned for PHP 6.)