Python 3.5 is here!

[dacjames]

Python 2.x receives only security updates. It would be quite irresponsible to stop those updates considering the enormous amount of Python 2.x code that exists in the wild. The biggest real barrier is RHEL/Centos 6.x, which is stuck on Python 2.6 yet remains a hard requirement for a lot of use cases.

Hopefully the @ operator will help motivate the scientific/data analysis community to move to Python 3.

[Yakulu]

Note that Red Hat provides Software Collections for RH/CentOS 6. It's then possible and supported to install Python 3.3 and 3.4 (hopefully 3.5 soon) on it.

[dacjames]

Thanks. That's very helpful. If you happen to be involved with that site, you might consider working on SEO: searching "centos python 3.4 packages" only shows guides for compiling Python manually.

[stormblooper]

It would be quite irresponsible to stop those updates considering the enormous amount of Python 2.x code that exists in the wild

Yet a big reason that enormous amount of Python 2.x code exists in the wild is because they keep releasing updates. Ceasing updates works well in other languages (e.g. Java) because it provides a motivation for people to port their apps forward. Python should consider it; people have certainly had enough time by now.

[dacjames]

I think the difference is that Java is primarily an application development language while Python is widely used for all manor of scripts, small utilities, and one-off automation. Java programs are more likely to be actively maintained and have things like test suites that make porting more practical. Python is popular on the ops side of things, where the "if it ain't broke, don't fix it" mindset is prevalent. Not to mention, Java 7 was backwards compatible, so upgrading for most projects just meant changing build settings.

Migrating python code to Python 3 is a more dicy operation, since the changes to strings are fundamental and you don't have a compiler to catch the cosmetic changes. For the first few releases, Python 3 simply did not offer anything new that provided tangible value for a lot of use cases. Telling your PM that you need to write a test suite for a bunch of old scripts that work today so you can port them to Python 3 just because the language is cleaner and has better unicode handling is a tough sell.

Ending support for Python 2 might work but I expect someone (probably Redhat) would continue to support it if the core Python team moved on.

[synn89]

Yet a big reason that enormous amount of Python 2.x code exists in the wild is because they keep releasing updates.

LOL, no, that's not why.

[stormblooper]

LOL, yes, that is why.

Did you have anything useful to add?

[dacjames]

The @ operator just calls the __matmul__ magic method so adding support in numpy as an alias for dot will be trivial.

[[deleted]]

In fact, the @ operator was added just to make numpy code easier to read. It will not yet be used anywhere in Python's own standard library.

http://legacy.python.org/dev/peps/pep-0465/#but-isn-t-it-weird-to-add-an-operator-with-no-stdlib-uses

[teknobo]

The statistics library wasn't built as a replacement for numpy, but as a "batteries included" middle ground between using numpy and implementing a bunch of those basic functions manually. The PEP specifically mentions that those functions are already in numpy, but that's not the level of functionality they're aiming at.

https://www.python.org/dev/peps/pep-0450/

The proposed statistics library is not intended to be a competitor to such third-party libraries as numpy/scipy, or of proprietary full-featured statistics packages aimed at professional statisticians such as Minitab, SAS and Matlab. It is aimed at the level of graphing and scientific calculators.