10 ms·

Python 3.7.2 and 3.6.8 are now available

90 points by webology 8y ago

fromthestart 8y ago
Something I've been wondering for years: I understand the rift between 2.x and 3.x.. But what is the rationale for maintaining multiple 3.x branches? And how do I choose the right branch for a fresh project? From experience, it seems like it doesn't really matter.
- jasongrout 8y ago
  From the announcement in the linked page: >> Python 3.6.8 is planned to be the last bugfix release of Python 3.6. Per our support policy, we plan to provide security fixes for Python 3.6 as needed through 2021, five years following its initial release.
- orf 8y ago
  Choose the latest 3.x release, unless you have some dependencies that don't work with the latest release (yet). There are differences between 3.x releases, and things like security issues or bugs need to be fixed. Saying "well duh just upgrade" isn't acceptable.
- sdoering 8y ago
  Well, as described in the OC 3.6.8 is a bugfix release for the 3.6 branch. Whoever needs to ensure compatibility with the featureset of 3.6 and not risk incompatibilities with 3.7 but wants bugfixes would use the latest 3.6. Everybody interested in the new features from 3.7 would use the latest version here. As python can introduce minor "breaking" changes this is quite a good way of ensuring compatibility.
- shepardrtc 8y ago
  Per the 3.6 release schedule[1], 3.6 was the stable branch until the final release of 3.7.0. After that, it was to receive two more bug fix releases and then switch over to security fixes. 3.7.0 final was released a few months ago, so this is the last bugfix release for 3.6.x. 3.7.0 is now considered "stable". However, 3.6.8 will still receive security fixes for anyone that is depending on it. This is generally done for those who want "stable" releases with minimal bug fixes. The 3.7 branch has newer features and therefore, potentially more bugs. If you want the latest stable version, get 3.7.0. If you want the latest version, get 3.7.2. [1] https://www.python.org/dev/peps/pep-0494/ https://www.python.org/dev/peps/pep-0494/
  - fromthestart 8y ago
    How does that justify 4 different 3.x branches continually updated in the last year, from 3.4 to 3.7? That still doesn't explain why it makes sense for python devs to be split among what, 4 different 3.x branches in the last year? I can understand keeping one stable LTS branch and one "up to date" branch, but the current system seems like a waste of resources and extra complexity, though I assume there's a good reason I'm not familiar with. For example, 3.4 .9 was released after 3.7.0. [1] Maybe I'm just missing something about the numbering scheme? 1.https://www.python.org/downloads https://www.python.org/downloads
    - ProblemFactory 8y ago
      All Linux distributions and MacOS ship with Python, and many users of Python stick to the OS-provided version without installing the latest and greatest on their own. For example, they might only upgrade major Python versions (3.x) once they migrate from Ubuntu 16.04 LTS to 18.04 LTS or even directly four years to 20.04 LTS. Whichever Python version is available by default there becomes the next Python LTS for them. For now, all versions since 3.4 receive occasional security and bug fixes to make all of them are "stable". New features are only adopted with a major version (3.x) bump. I have not heard of the Python community complaining about this being too much work - after all improvement work is only done in the latest version, old versions just get backported bug fixes.
    - theptip 8y ago
      > I can understand keeping one stable LTS branch and one "up to date" branch If you did that then lots of distro packagers would just stay on the LTS until the next one comes along, and so you'd increase the number of users that are on older versions. With the selected approach, there is more work involved to backport a fix to the 4-5 supported versions, but this gives the benefit that OS distros can bump their Python versions more frequently, and so end users get updated Python3 features more often.
    - maxerickson 8y ago
      I guess you aren't missing anything. They do security releases for 5 years after the release of a minor version: https://devguide.python.org/devcycle/#security-branches https://devguide.python.org/devcycle/#security-branches Arbitrary, but not senseless or anything. If you drill into the security releases, they are pretty small patches backported from later releases, not a huge burden.
- quietbritishjim 8y ago
  This doesn't invalidate your question, but an interesting comparison: Historically the same situation of fairly regular minor releases was the norm, even for Python 2.x. It was only when Python 3 was released that Python 2.x was fixed on Python 2.7 for a while (for a generous definition of "a while"), so that was the anomaly.
- blattimwind 8y ago
  > But what is the rationale for maintaining multiple 3.x branches? Introducing new features bears an elevated risk of breaking thingss. Hence stable systems (and in extension, stable distributions like Debian) tend to use stable, bug and security fix only branches. This used to be more common.
- brianwawok 8y ago
  A major library I use doesn’t work on 3.7 yet, so still stuck on 3.6. It’s sure nice to get bug fixes and security while I wait for the PR of my library to get merged. Very rare everyone can jump versions especially when there are syntax changes. In my case it’s around imports.
  - hartator 8y ago
    Imports changed between 3.6 and 3.7?
    - ggm 8y ago
      I think they mean it's around things I depend on via import which aren't yet ported to 3.x
- qwerty456127 8y ago
  I think exactly the same. The only reasons I can imagine are that perhaps a feature can happen to be deprecated between these releases and the internals of the implementation of a particular part can change significantly and this can lead to notable change in performance of a particular algorithm some production service may rely on. As for the right choice for a fresh project - IMHO it's always the latest working version available, even a beta as long as everything you need works fine in it.
- stadeschuldt 8y ago
  For a new project you definitely want to use Python 3 as Python will be EOL in 2020. For new projects I tend to favor Python 3.7 over 3.6. But sometimes I have to fall back to 3.6 because some packages have not been updated yet and I don't want to install them from Git(Hub) (e.g. GeoPandas through pyproj).
  - nerdwaller 8y ago
    Another important library not supporting 3.7 is celery (distributed task queuing). Otherwise I also favor 3.7 (for contextvars and dataclasses).
jacob019 8y ago
A hefty list if improvements to asyncio. When I tried working with asyncio in Python 3.4 it seemed half-baked and unpythonic. I look forward to trying out the more mature implementation.
- uranusjr 8y ago
  I am responsible for maitaining a Python 3.4 asyncio app at work, and recently in charge of building a new (not replacing) system in 3.7. The difference is truly enormous in a very pleasant way.
bratao 8y ago
Python 3.7 is a great release. Finally is faster than 2.7 for almost all of our use cases.
b_tterc_p 8y ago
Dicts now retain order now (in other words all dicts are ordered dicts). I support this, but I also guarantee this is going to bite me in the ass at least once sharing notebooks with someone on an older version of python as I expect to use this liberally. Ah well.
- bratao 8y ago
  Just to clarify. This behavior is expected since 3.6: As of Python 3.6, for the CPython implementation of Python, dictionaries remember the order of items inserted. This is considered an implementation detail in Python 3.6; you need to use OrderedDict if you want insertion ordering that's guaranteed across other implementations of Python. As of Python 3.7, this is no longer an implementation detail and instead becomes a language feature. [1] https://stackoverflow.com/questions/39980323/are-dictionaries-ordered-in-python-3-6 https://stackoverflow.com/questions/39980323/are-dictionarie...
  - blattimwind 8y ago
    CPython implementation detail vs. Python language feature remains a relatively meaningless distinction.
    - anticensor 8y ago
      CPython is not the only Python interpreter out there.
      - JeremyBanks 8y ago
        The documentation sometimes suggests otherwise, but since there is no Python language specification, declaring something "part of the language" seems to have no meaning if it's not "implemented in CPython". PyPy has had ordered dicts for longer than CPython, and Jython and IronPython don't look like they're ever going to support Python 3, so I'm not sure who this declaration is even even hypothetically relevant to.

90 points by webology 8y ago

Something I've been wondering for years: I understand the rift between 2.x and 3.x.. But what is the rationale for maintaining multiple 3.x branches? And how do I choose the right branch for a fresh project? From experience, it seems like it doesn't really matter.

jasongrout 8y ago
From the announcement in the linked page: >> Python 3.6.8 is planned to be the last bugfix release of Python 3.6. Per our support policy, we plan to provide security fixes for Python 3.6 as needed through 2021, five years following its initial release.
orf 8y ago
Choose the latest 3.x release, unless you have some dependencies that don't work with the latest release (yet). There are differences between 3.x releases, and things like security issues or bugs need to be fixed. Saying "well duh just upgrade" isn't acceptable.
sdoering 8y ago
Well, as described in the OC 3.6.8 is a bugfix release for the 3.6 branch. Whoever needs to ensure compatibility with the featureset of 3.6 and not risk incompatibilities with 3.7 but wants bugfixes would use the latest 3.6. Everybody interested in the new features from 3.7 would use the latest version here. As python can introduce minor "breaking" changes this is quite a good way of ensuring compatibility.
shepardrtc 8y ago
Per the 3.6 release schedule[1], 3.6 was the stable branch until the final release of 3.7.0. After that, it was to receive two more bug fix releases and then switch over to security fixes. 3.7.0 final was released a few months ago, so this is the last bugfix release for 3.6.x. 3.7.0 is now considered "stable". However, 3.6.8 will still receive security fixes for anyone that is depending on it. This is generally done for those who want "stable" releases with minimal bug fixes. The 3.7 branch has newer features and therefore, potentially more bugs. If you want the latest stable version, get 3.7.0. If you want the latest version, get 3.7.2. [1] https://www.python.org/dev/peps/pep-0494/ https://www.python.org/dev/peps/pep-0494/
- fromthestart 8y ago
  How does that justify 4 different 3.x branches continually updated in the last year, from 3.4 to 3.7? That still doesn't explain why it makes sense for python devs to be split among what, 4 different 3.x branches in the last year? I can understand keeping one stable LTS branch and one "up to date" branch, but the current system seems like a waste of resources and extra complexity, though I assume there's a good reason I'm not familiar with. For example, 3.4 .9 was released after 3.7.0. [1] Maybe I'm just missing something about the numbering scheme? 1.https://www.python.org/downloads https://www.python.org/downloads
  - ProblemFactory 8y ago
    All Linux distributions and MacOS ship with Python, and many users of Python stick to the OS-provided version without installing the latest and greatest on their own. For example, they might only upgrade major Python versions (3.x) once they migrate from Ubuntu 16.04 LTS to 18.04 LTS or even directly four years to 20.04 LTS. Whichever Python version is available by default there becomes the next Python LTS for them. For now, all versions since 3.4 receive occasional security and bug fixes to make all of them are "stable". New features are only adopted with a major version (3.x) bump. I have not heard of the Python community complaining about this being too much work - after all improvement work is only done in the latest version, old versions just get backported bug fixes.
  - theptip 8y ago
    > I can understand keeping one stable LTS branch and one "up to date" branch If you did that then lots of distro packagers would just stay on the LTS until the next one comes along, and so you'd increase the number of users that are on older versions. With the selected approach, there is more work involved to backport a fix to the 4-5 supported versions, but this gives the benefit that OS distros can bump their Python versions more frequently, and so end users get updated Python3 features more often.
  - maxerickson 8y ago
    I guess you aren't missing anything. They do security releases for 5 years after the release of a minor version: https://devguide.python.org/devcycle/#security-branches https://devguide.python.org/devcycle/#security-branches Arbitrary, but not senseless or anything. If you drill into the security releases, they are pretty small patches backported from later releases, not a huge burden.
quietbritishjim 8y ago
This doesn't invalidate your question, but an interesting comparison: Historically the same situation of fairly regular minor releases was the norm, even for Python 2.x. It was only when Python 3 was released that Python 2.x was fixed on Python 2.7 for a while (for a generous definition of "a while"), so that was the anomaly.
blattimwind 8y ago
> But what is the rationale for maintaining multiple 3.x branches? Introducing new features bears an elevated risk of breaking thingss. Hence stable systems (and in extension, stable distributions like Debian) tend to use stable, bug and security fix only branches. This used to be more common.
brianwawok 8y ago
A major library I use doesn’t work on 3.7 yet, so still stuck on 3.6. It’s sure nice to get bug fixes and security while I wait for the PR of my library to get merged. Very rare everyone can jump versions especially when there are syntax changes. In my case it’s around imports.
- hartator 8y ago
  Imports changed between 3.6 and 3.7?
  - ggm 8y ago
    I think they mean it's around things I depend on via import which aren't yet ported to 3.x
qwerty456127 8y ago
I think exactly the same. The only reasons I can imagine are that perhaps a feature can happen to be deprecated between these releases and the internals of the implementation of a particular part can change significantly and this can lead to notable change in performance of a particular algorithm some production service may rely on. As for the right choice for a fresh project - IMHO it's always the latest working version available, even a beta as long as everything you need works fine in it.
stadeschuldt 8y ago
For a new project you definitely want to use Python 3 as Python will be EOL in 2020. For new projects I tend to favor Python 3.7 over 3.6. But sometimes I have to fall back to 3.6 because some packages have not been updated yet and I don't want to install them from Git(Hub) (e.g. GeoPandas through pyproj).
- nerdwaller 8y ago
  Another important library not supporting 3.7 is celery (distributed task queuing). Otherwise I also favor 3.7 (for contextvars and dataclasses).

jacob019 8y ago

A hefty list if improvements to asyncio. When I tried working with asyncio in Python 3.4 it seemed half-baked and unpythonic. I look forward to trying out the more mature implementation.

uranusjr 8y ago
I am responsible for maitaining a Python 3.4 asyncio app at work, and recently in charge of building a new (not replacing) system in 3.7. The difference is truly enormous in a very pleasant way.

bratao 8y ago

Python 3.7 is a great release. Finally is faster than 2.7 for almost all of our use cases.

b_tterc_p 8y ago

Dicts now retain order now (in other words all dicts are ordered dicts). I support this, but I also guarantee this is going to bite me in the ass at least once sharing notebooks with someone on an older version of python as I expect to use this liberally. Ah well.

bratao 8y ago
Just to clarify. This behavior is expected since 3.6: As of Python 3.6, for the CPython implementation of Python, dictionaries remember the order of items inserted. This is considered an implementation detail in Python 3.6; you need to use OrderedDict if you want insertion ordering that's guaranteed across other implementations of Python. As of Python 3.7, this is no longer an implementation detail and instead becomes a language feature. [1] https://stackoverflow.com/questions/39980323/are-dictionaries-ordered-in-python-3-6 https://stackoverflow.com/questions/39980323/are-dictionarie...
- blattimwind 8y ago
  CPython implementation detail vs. Python language feature remains a relatively meaningless distinction.
  - anticensor 8y ago
    CPython is not the only Python interpreter out there.
    - JeremyBanks 8y ago
      The documentation sometimes suggests otherwise, but since there is no Python language specification, declaring something "part of the language" seems to have no meaning if it's not "implemented in CPython". PyPy has had ordered dicts for longer than CPython, and Jython and IronPython don't look like they're ever going to support Python 3, so I'm not sure who this declaration is even even hypothetically relevant to.