5 ms·

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 idios

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.)
        petre 4y ago
        Incorrect, Raku(do) is not the VM. It's MoarVM (or JVM but that one is trailing behind). Rakudo is the reference implementation. Also you should think in terms of Perl 5 -> 7. Raku is the language formally known as Perl 6. Perl 7 isn't undoing anything, it will be the successor to Perl 5. Perl 7 should have been 5.32 with saner defaults, but of course it's now going to take another 20 years of bikeshedding until this is happening. https://www.perl.com/article/announcing-perl-7/ https://www.perl.com/article/announcing-perl-7/
        raiph 4y ago
        I get how you (and perhaps others) might think it's as you say. But I can tell you're not saying what you've said based on knowing it to be true but guessing it to be so. And while your guess isn't a surprising one given natural assumptions due to the names "Perl", "Perl 5", "Perl 6", and "Perl 7", it doesn't correspond to what has actually happened. Anyone keeping up with the latest release of the Perl language has had near zero breakage for decades. (Indeed Perl has a well deserved reputation for having an outstanding track record in this regard compared to almost all other mainstream PLs.) I personally see every likelihood Perl 7 will extend that track record, though of course my crystal ball prognostications are necessarily based purely on what I see. No one using P6 or Raku had a huge breaking change from Perl 5. No one using P6/Raku will have another one going to Perl 7. If you presume Raku and Perl are different languages you'll get the essence of what has actually happened so far, and seems likely to be more or less true for the rest of this decade at least.
    - munificent 4y ago
      I don't think people considered Perl 6 a "mistake". It's more that they realized that it wasn't a successor to Perl 5 and is instead a separate language. The language itself isn't a mistake, it was treating it as the next version that was. The Perl community may be attempting to "fix" that mistake with Perl 7, but the damage has been done. I think Perl 6 fractured the community so hard and scared away so many users that both Perl 7 and Raku are likely to be minor languages for the foreseeable future. If either of them has legs, I think it's likely to be Raku. Because Raku is at least an interesting language with a lot of really interesting, powerful language features. Perl 5/7 by virtue of its history, is mostly just another dynamic scripting language, but one with a particularly unfriendly syntax. Aside from CPAN and inertia, I think there is relatively little reason to write new Perl 5/7 code when PHP, Python, Ruby, and JavaScript are out there.
      - petre 4y ago
        Raku is too slow for no obvious reason, plus every lib has to be rewritten from scratch, including the good and mature ones from Perl. There are more interesting things happening with Ruby and Python. In fact there are Python libs for obscure stuff like CAN-bus and ISO-TP. Want to talk to a vehicle ECU? It can be done with Python. There's also lack of momentum and quite a lot of bikeshedding in the Perl community. There were attempts to modernise Perl by rurban and others, but they were met with unecessary resistence. Without community support they all ended up as one man shows. Perl is pretty much a dead end. You are hearing this from someone who still writes Perl code every day for work. My latest proof of concept was done in Ruby and it will probably end up as production code.
        lizmat 4y ago
        > Raku is too slow for no obvious reason I wonder when it was the last time you tried Raku. Or compared it to a Perl script with Moose. > plus every lib has to be rewritten from scratch, including the good and mature ones from Perl. The good and mature ones from Perl can be used from Raku with Inline::Perl5.
        4y ago
- kortex 4y ago
  It needed to be done; there were several choices in python 1/2 holding the language back, that all but necessitated breaking changes. Mostly with string/bytes/unicode handling. And the non-breaking route would have been a long term pain. They didn't decide to break over print() and cosmetic changes, it runs way deeper.
viraptor 4y ago
I think you're missing how deep the function reference change goes in standard code. What about unittest mocks? Conditional module loading? Enabling/disabling tracing features? I'd bet there's some dynamic function reference assignment that happens during python console startup. It's not unreasonable. It's just what the language makes easy and useful. It's still used much less than for example method aliasing in Ruby which has about the same result.
duckerude 4y ago
> just like in every other mainstream language JavaScript doesn't do this, you can replace properties of window at will. I don't think Ruby does it, or Lua. PHP probably does it under some circumstances in modern versions but only because it's remarkably un-dynamic for an interpreted language. This is normal fare for high-level interpreted languages, for better or worse.
- SemanticStrengh 4y ago
  and yet I'm pretty sure JS can inline just fine
  - munificent 4y ago
    If by "just fine" you mean, "with incredible engineering resources funded by a small number of large companies with deep pockets and with some performance cost to check that the optimization is still valid", yes.
  - duckerude 4y ago
    It can, but it doesn't have a "do reasonable things" mode. Instead it notices when you do something unreasonable and undoes its optimizations.
  - masklinn 4y ago
    Sure, so can pypy. But that means you have to add all sorts of dependency tracking, such that you are able to deoptimise any function affected by mutation on things which were optimised in or out. This means your complexity increases very fast, very high, before you can have anything which actually works.

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.)
      - petre 4y ago
        Incorrect, Raku(do) is not the VM. It's MoarVM (or JVM but that one is trailing behind). Rakudo is the reference implementation. Also you should think in terms of Perl 5 -> 7. Raku is the language formally known as Perl 6. Perl 7 isn't undoing anything, it will be the successor to Perl 5. Perl 7 should have been 5.32 with saner defaults, but of course it's now going to take another 20 years of bikeshedding until this is happening. https://www.perl.com/article/announcing-perl-7/ https://www.perl.com/article/announcing-perl-7/
      - raiph 4y ago
        I get how you (and perhaps others) might think it's as you say. But I can tell you're not saying what you've said based on knowing it to be true but guessing it to be so. And while your guess isn't a surprising one given natural assumptions due to the names "Perl", "Perl 5", "Perl 6", and "Perl 7", it doesn't correspond to what has actually happened. Anyone keeping up with the latest release of the Perl language has had near zero breakage for decades. (Indeed Perl has a well deserved reputation for having an outstanding track record in this regard compared to almost all other mainstream PLs.) I personally see every likelihood Perl 7 will extend that track record, though of course my crystal ball prognostications are necessarily based purely on what I see. No one using P6 or Raku had a huge breaking change from Perl 5. No one using P6/Raku will have another one going to Perl 7. If you presume Raku and Perl are different languages you'll get the essence of what has actually happened so far, and seems likely to be more or less true for the rest of this decade at least.
  - munificent 4y ago
    I don't think people considered Perl 6 a "mistake". It's more that they realized that it wasn't a successor to Perl 5 and is instead a separate language. The language itself isn't a mistake, it was treating it as the next version that was. The Perl community may be attempting to "fix" that mistake with Perl 7, but the damage has been done. I think Perl 6 fractured the community so hard and scared away so many users that both Perl 7 and Raku are likely to be minor languages for the foreseeable future. If either of them has legs, I think it's likely to be Raku. Because Raku is at least an interesting language with a lot of really interesting, powerful language features. Perl 5/7 by virtue of its history, is mostly just another dynamic scripting language, but one with a particularly unfriendly syntax. Aside from CPAN and inertia, I think there is relatively little reason to write new Perl 5/7 code when PHP, Python, Ruby, and JavaScript are out there.
    - petre 4y ago
      Raku is too slow for no obvious reason, plus every lib has to be rewritten from scratch, including the good and mature ones from Perl. There are more interesting things happening with Ruby and Python. In fact there are Python libs for obscure stuff like CAN-bus and ISO-TP. Want to talk to a vehicle ECU? It can be done with Python. There's also lack of momentum and quite a lot of bikeshedding in the Perl community. There were attempts to modernise Perl by rurban and others, but they were met with unecessary resistence. Without community support they all ended up as one man shows. Perl is pretty much a dead end. You are hearing this from someone who still writes Perl code every day for work. My latest proof of concept was done in Ruby and it will probably end up as production code.
      - lizmat 4y ago
        > Raku is too slow for no obvious reason I wonder when it was the last time you tried Raku. Or compared it to a Perl script with Moose. > plus every lib has to be rewritten from scratch, including the good and mature ones from Perl. The good and mature ones from Perl can be used from Raku with Inline::Perl5.
        4y ago
kortex 4y ago
It needed to be done; there were several choices in python 1/2 holding the language back, that all but necessitated breaking changes. Mostly with string/bytes/unicode handling. And the non-breaking route would have been a long term pain. They didn't decide to break over print() and cosmetic changes, it runs way deeper.

viraptor 4y ago

I think you're missing how deep the function reference change goes in standard code. What about unittest mocks? Conditional module loading? Enabling/disabling tracing features? I'd bet there's some dynamic function reference assignment that happens during python console startup. It's not unreasonable. It's just what the language makes easy and useful. It's still used much less than for example method aliasing in Ruby which has about the same result.

duckerude 4y ago

> just like in every other mainstream language JavaScript doesn't do this, you can replace properties of window at will. I don't think Ruby does it, or Lua. PHP probably does it under some circumstances in modern versions but only because it's remarkably un-dynamic for an interpreted language. This is normal fare for high-level interpreted languages, for better or worse.

SemanticStrengh 4y ago
and yet I'm pretty sure JS can inline just fine
- munificent 4y ago
  If by "just fine" you mean, "with incredible engineering resources funded by a small number of large companies with deep pockets and with some performance cost to check that the optimization is still valid", yes.
- duckerude 4y ago
  It can, but it doesn't have a "do reasonable things" mode. Instead it notices when you do something unreasonable and undoes its optimizations.
- masklinn 4y ago
  Sure, so can pypy. But that means you have to add all sorts of dependency tracking, such that you are able to deoptimise any function affected by mutation on things which were optimised in or out. This means your complexity increases very fast, very high, before you can have anything which actually works.