
Python 3.7.2 and 3.6.8 are now available - webology
https://pythoninsider.blogspot.com/2018/12/python-372-and-368-are-now-available.html
======
fromthestart
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.

~~~
shepardrtc
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
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)

~~~
theptip
> 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.

------
b_tterc_p
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
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-
dictionarie...](https://stackoverflow.com/questions/39980323/are-dictionaries-
ordered-in-python-3-6)

~~~
blattimwind
CPython implementation detail vs. Python language feature remains a relatively
meaningless distinction.

~~~
anticensor
CPython is not the only Python interpreter out there.

~~~
JeremyBanks
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.

~~~
richardwhiuk
It's relevant in the fact that you shouldn't rely on it as a programmer prior
to this release. Changing it would have been considered a none breaking
change.

~~~
JeremyBanks
Good point.

------
jacob019
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
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
Python 3.7 is a great release. Finally is faster than 2.7 for almost all of
our use cases.

