5 ms·

When to Switch to Python 3.8

22 points by itamarst 7y ago

ebg13 7y ago
This feels like blogspam where "Python 3.8" can be replaced by literally any new version of anything.
- 87zuhjkas 7y ago
  Maybe I could write a bot for this and then make post about the creation of the bot.
- fermenflo 7y ago
  Yeah, this really didn't state anything novel that anyone who's even aware of Python 3.8 wouldn't have already known...
- tristor 7y ago
  I agree with you wholeheartedly. My expectation based on the domain was perhaps there were performance regressions still being worked out in Python 3.8 that would be revealed, but in fact performance isn't even mentioned.
jordigh 7y ago
I know this is a tired subject, but as Mercurial is nearing its multi-year effort to upgrade to Python 3, patience wears thin: https://twitter.com/indygreg/status/1187069501424062464 https://twitter.com/indygreg/status/1187069501424062464 Mercurial was in fact one of important reasons for why the Python 2 deprecation was pushed back five years. We met with Guido at Pycon 2014 in Montreal and asked for an extension, which he granted. Back then Python itself was using Mercurial, so maybe that's why our opinion carried some weight. We weren't the only ones, but we were one of the vocal ones.
- pbhjpbhj 7y ago
  Could you precis why it's taking multiple years? Surely there's a formal equivalence that could be automatically implemented wrt the code itself?
  - lidHanteyk 7y ago
    Python 2 and Python 3 are distinct languages with a lot of commonalities. It's a difficult port that cannot be automated.
    - kevin_thibedeau 7y ago
      It's easy to gradually upgrade Py2 code. Start introducing the future imports. Unicode handling is the only tricky one (though not so bad when the codecs module is consistently used). Then start running files through 2to3 and making the code forward compatible. This can be done over a long time span while maintaining full 2.7 compatibility.
      - marmada 7y ago
        These types of comments are confusing. The developer of Mercurial has stated that it took/is taking them several years to port to Python 3. I'm inclined to believe them compared to some random stranger who asserts that it should be easy for Mercurial to be ported to Python 3. Unless you were saying that most other/non-Mercurial programs are easy to port to Python 3, which could be true.
      - lidHanteyk 7y ago
        Have you ever carried an application using Django, or Twisted, or Zope, through this process? It is not easy. Many different libraries with various incompatibilities and versions can lead to real difficulties merely in upgrading for security releases. Additionally, unless one is containerized, one must contend with the underlying platform's issues, as the platform must also switch from Python 2 to Python 3. I understand your opinion: It is the party line. But it doesn't actually help much when the process as described will take years and people only have months, and this is further worsened by the fact that PSF did not have to deprecate the entire Python 2 ecosystem in order to stop supporting CPython 2.7.
- ken 7y ago
  Back when I looked at it, at least, Mercurial had the strangest and most non-idiomatic Python I'd ever seen. It doesn't surprise me it's been trouble to upgrade. Mercurial's curious implementation is also the reason I gave up trying to do anything with it. I love the idea of a popular DVCS written in a HLL, but it looked halfway to C.
  - jordigh 7y ago
    > Mercurial had the strangest and most non-idiomatic Python I'd ever seen. It's not so bad. We just use a lot of abbreviations, but you get used to them. There's also a reason for a lot of the ways it's written: backwards compatibility. We supported Python 2.4 until a couple of years ago. This meant you had to do "x and y or z" instead of "y if x else z" because the ternary operator wasn't available in older releases. This wasn't because we like old software, but because our users do. A data-storage solution needs to be stable over very long periods of time. You don't want to be unable to access your repo because you're on an old machine. A DVCS is too important to force your users to be chasing after the latest release all the time. Another reason for Mercurial's style is to avoid unnecessary function lookups or calls and other quirks of the Python interpreter. Something as simple as for x in y: thing.doit(x) can have a noticeable speedup if you instead do doit = thing.doit for x in y: doit(x) because Python just takes a while doing function lookups. Our users notice those milliseconds of difference because they want "hg status" or "hg log" to be nearly instantaneous.
    - bipson 7y ago
      May I ask why you are even using Python, if you need to work around the language in such ways? These non-idiomatic uses might be shedding a few ms, yet they ruin the readability and maintainability of the code, most of all all tools like 2to3? Why not another (non-interpreted and thus faster) language? One where the idoms work in your favor? Also, no need to support releases from 2004 and having to groan about it.
Lendal 7y ago
Oh come on. You can do useful work without a linter and autoformatter for a couple of weeks. Geez. Especially for Python, of all languages.
skwb 7y ago
Easy: when I can safely and easily install tensorflow on python 3.8 [1.]. 1. https://github.com/tensorflow/tensorflow/issues/33374#event-2714817436 https://github.com/tensorflow/tensorflow/issues/33374#event-...
simonblack 7y ago
When a minor-point upgrade happens and it breaks backward-compatibility, there is something very wrong with the versioning or the major name of the software. Either the major-version number should be changed (Python 31 to Python 32) or the project name should be changed (Python to Boa). This is also a very common problem with GTK+ and some other major pieces of software.

22 points by itamarst 7y ago

ebg13 7y ago

This feels like blogspam where "Python 3.8" can be replaced by literally any new version of anything.

87zuhjkas 7y ago
Maybe I could write a bot for this and then make post about the creation of the bot.
fermenflo 7y ago
Yeah, this really didn't state anything novel that anyone who's even aware of Python 3.8 wouldn't have already known...
tristor 7y ago
I agree with you wholeheartedly. My expectation based on the domain was perhaps there were performance regressions still being worked out in Python 3.8 that would be revealed, but in fact performance isn't even mentioned.

jordigh 7y ago

I know this is a tired subject, but as Mercurial is nearing its multi-year effort to upgrade to Python 3, patience wears thin: https://twitter.com/indygreg/status/1187069501424062464 https://twitter.com/indygreg/status/1187069501424062464 Mercurial was in fact one of important reasons for why the Python 2 deprecation was pushed back five years. We met with Guido at Pycon 2014 in Montreal and asked for an extension, which he granted. Back then Python itself was using Mercurial, so maybe that's why our opinion carried some weight. We weren't the only ones, but we were one of the vocal ones.

pbhjpbhj 7y ago
Could you precis why it's taking multiple years? Surely there's a formal equivalence that could be automatically implemented wrt the code itself?
- lidHanteyk 7y ago
  Python 2 and Python 3 are distinct languages with a lot of commonalities. It's a difficult port that cannot be automated.
  - kevin_thibedeau 7y ago
    It's easy to gradually upgrade Py2 code. Start introducing the future imports. Unicode handling is the only tricky one (though not so bad when the codecs module is consistently used). Then start running files through 2to3 and making the code forward compatible. This can be done over a long time span while maintaining full 2.7 compatibility.
    - marmada 7y ago
      These types of comments are confusing. The developer of Mercurial has stated that it took/is taking them several years to port to Python 3. I'm inclined to believe them compared to some random stranger who asserts that it should be easy for Mercurial to be ported to Python 3. Unless you were saying that most other/non-Mercurial programs are easy to port to Python 3, which could be true.
    - lidHanteyk 7y ago
      Have you ever carried an application using Django, or Twisted, or Zope, through this process? It is not easy. Many different libraries with various incompatibilities and versions can lead to real difficulties merely in upgrading for security releases. Additionally, unless one is containerized, one must contend with the underlying platform's issues, as the platform must also switch from Python 2 to Python 3. I understand your opinion: It is the party line. But it doesn't actually help much when the process as described will take years and people only have months, and this is further worsened by the fact that PSF did not have to deprecate the entire Python 2 ecosystem in order to stop supporting CPython 2.7.
ken 7y ago
Back when I looked at it, at least, Mercurial had the strangest and most non-idiomatic Python I'd ever seen. It doesn't surprise me it's been trouble to upgrade. Mercurial's curious implementation is also the reason I gave up trying to do anything with it. I love the idea of a popular DVCS written in a HLL, but it looked halfway to C.
- jordigh 7y ago
  > Mercurial had the strangest and most non-idiomatic Python I'd ever seen. It's not so bad. We just use a lot of abbreviations, but you get used to them. There's also a reason for a lot of the ways it's written: backwards compatibility. We supported Python 2.4 until a couple of years ago. This meant you had to do "x and y or z" instead of "y if x else z" because the ternary operator wasn't available in older releases. This wasn't because we like old software, but because our users do. A data-storage solution needs to be stable over very long periods of time. You don't want to be unable to access your repo because you're on an old machine. A DVCS is too important to force your users to be chasing after the latest release all the time. Another reason for Mercurial's style is to avoid unnecessary function lookups or calls and other quirks of the Python interpreter. Something as simple as for x in y: thing.doit(x) can have a noticeable speedup if you instead do doit = thing.doit for x in y: doit(x) because Python just takes a while doing function lookups. Our users notice those milliseconds of difference because they want "hg status" or "hg log" to be nearly instantaneous.
  - bipson 7y ago
    May I ask why you are even using Python, if you need to work around the language in such ways? These non-idiomatic uses might be shedding a few ms, yet they ruin the readability and maintainability of the code, most of all all tools like 2to3? Why not another (non-interpreted and thus faster) language? One where the idoms work in your favor? Also, no need to support releases from 2004 and having to groan about it.

Lendal 7y ago

Oh come on. You can do useful work without a linter and autoformatter for a couple of weeks. Geez. Especially for Python, of all languages.

skwb 7y ago

Easy: when I can safely and easily install tensorflow on python 3.8 [1.]. 1. https://github.com/tensorflow/tensorflow/issues/33374#event-2714817436 https://github.com/tensorflow/tensorflow/issues/33374#event-...

simonblack 7y ago

When a minor-point upgrade happens and it breaks backward-compatibility, there is something very wrong with the versioning or the major name of the software. Either the major-version number should be changed (Python 31 to Python 32) or the project name should be changed (Python to Boa). This is also a very common problem with GTK+ and some other major pieces of software.