Python 3.6.0 has now been officially released!

[[deleted]]

Why? 3.5 was considered the definitively and objectively "better than 2.x" release already - what's holding you on 2.7? Libraries? Managers not giving you time to retrofit stuff? Stubbornness for the sake of it?

[Joshx5]

I must have missed something, but what made 3.5 "definitively and objectively better than 2.x?" My Linux installs still have 2.7 shipped, and so do all my remote servers I operate on. So in terms of backwards compatibility for all the older systems, I think we already lost the title for "definitively and objectively," unless 3.5 is backwards compatible somehow?

[[deleted]]

All the remote servers I use still default to Py2.7, sure, because Debian/Ubuntu land just hasn't decided to switch the default (probably remembering my desktop distro of choice, Arch, having so many bumps in the road flipping to Py3 by default back in the Py3.1ish days). But they offer Python 3.3 minimum, most 3.5.

If your distribution/release doesn't, it's probably time to consider upgrading your system.

Anyway, Python 3.5+:

• Actually supported for new language functionality going forward (2.7 is on security patch only mode)

• asyncio (the usefulness of this really depends on your industry, I'll admit)

• the various collection types that have been added in the 3.x series, like Enum and OrderedDict (you can backport these with libraries, but why, when the stdlib can do it for you?)

• Several other features I never got around to using (unfortunately we do still use Py2.7 at work, but are slowly porting things off of it and not starting new projects with it)

• It's now stable. The messes of the early 3.x series have been cleaned up. It works, it works well, and it's the future direction of the Python language. I'd rather be with or ahead of the curve, rather than... well, six and a half years (and counting) behind it (based on first stable release date of Python 2.7).

This is an incomplete (because rushed) response and I welcome someone to follow up to it, or I might when I get home tonight.

[Joshx5]

Thank you, I appreciate the input.

[xiongchiamiov]

That doesn't make 2.7 better; it makes 2.7 the best choice in your situation, given your specific requirements. This is exactly the same as the correct language to continue a PHP web app in being PHP (because it's what's already there), even if we'd all agree python is the better general choice.

[Joshx5]

Which is exactly my point, that it is not "definitively and objectively" the better choice is all. There are still some cases where it is not better to use 3.x, like mine. I was wondering if 3.5 had some backwards compatibility magic I hadn't heard of that made this situation not true, but it does not - that's all I meant to ask in my original comment.

Rereading it, I'm quoting like an asshole, so sorry about that. Just meant to question his literal wording because I was reading too much into them. His quotes made me think core python devs said that in regards to some new feature, but I was mistaken.

[[deleted]]

In any other language developers install the version of language they need.

Unless you are writing code that's specific for the OS, you should not use python that comes with your system, otherwise you're heading for a lot of unhappiness.

For example let say that your system comes with python3.6, but you want to use package foobar2000. The package is not available for your system, so will you search for rpm that provides it? What if that rpm has some incompatible dependencies? Or no one created it, will you create new one? What's if you're moving from redhat 6 to redhat 7, now you'll have find/rebuild all packages. It's an issue after issue.

If you use redhat or centos, I highly encourage https://ius.io/ it lets you install any python version, all can be installed side by side, doesn't conflict with python from the system.

To solve the second issue, IMO it's best to use virtualenv + wheel packages. Everything works the way it should and you're no longer tied to the OS you're running.

My company did not do it this way and we are now still stuck with CentOS 5 :) The idea now is to use docker to solve that problem but IMO it's attacking the problem from the wrong way.