It's Python, Not Python 2, Not Python 3 | Hacker News Reader

It's Python, Not Python 2, Not Python 3

medium.com

22 pointsgh117 comments

I fully agree with this sentiment. If you read the discussions, it sounds like Python 3 is an entirely different language which is definitely not the case. Porting code to Python 3 is really easy and involves no changes to the program flow or the APIs you use. Hardest to port is usually the Bytes/Unicode transition. In my projects, it fixed a few nasty Unicode bugs which was a nice bonus.

> Python 3 came out 2008, at the moment of writing this, it’s almost a decade and if your third party package has not been updated, then it’s really messed up.

Exactly. A library which has no Python 3 port in 2016 is going to be an maintenance burden either way, since it's not going to get support or security updates either. Many of those abandoned projects have been forked for Python 3 support, and active development continues there.

A number of new projects are Python 3-only.

Two years ago, I recommended new developers to stick with Python 2 for anything except toy projects (and use __future__ imports to make it easier to port later) because library support just wasn't there. Now it is, so it's an easy decision.

Porting to Python 3 means future-proofing the project - not only Python 2 will be EOL, but many libraries will drop Python 2 support.

http://www.python3statement.org/

1) most porting requires little to no change in logic flow regardless of the languages as long as they are the same paradigm (functional, oo, declarative, imperative, etc).

2) That's just not true. Python 2 is and will be better supported in general than Python 3. Does aws lambda or google even support Python 3 yet?

If anything it's Python 2.

Any time you alter code you must spend time to understand what you're doing. There are all sorts of overheads associated with simply touching a code file.

> A library which has no Python 3 port in 2016 is going to be an maintenance burden either way, since it's not going to get support or security updates either.

If you mean Python 2, it will still be supported until 2020 (and that's assuming they don't push back EOL again, which I hope they don't).

If you mean the libraries won't be supported, that's just not true. Most of the google api client libraries are Py2 only, for example, and are regularly updated.

I recommend Python 3 to everyone, and it's my first choice over Py2 for both personal and commercial stuff. Most of the time everything will work A-OK, or better. But sometimes you still have to use Python 2.

So, the problem is that the Python developers - in my opinion unneccessarily - broke backwards compatibility. There are two main problems - the print function, and str/unicode. They could just add two or three things, and I'd be completely satisfied. I hope they are self-descriptive:

    from __past__ import print_statement

    import unicode_string as str, bytestring as bytes
    import unicode_string as unicode, bytestring as str

    from python2 import legacy_module

... or equivalent comment options (a la "coding: utf8"), or iterpreter flags, or something like that. Perl 6 manages to load Perl 5, I don't see why this shouldn't be possible in Python.

Now you might say this is petty, why get worked up by something as minor as the print statement. But just because it is so minor, it feels so unneccessary and petty to remove it.

The str/unicode switch was also not handled optimally. There is a lot of code still broken. I just ported some code to Python 3 which uses Twisted, and found the FTP implementation does not work in Python3. It turns out this is really hard to fix, because FTP is not encoding aware, and bytestrings "I dont care right now what encoding this is"-strings are second class citizens in Python3.

It's a bit unfortunate that the Python developers get to decide what is defined as Python and what not. When something gets big, I believe you get certain responsibilites. You shouldn't just "break the world" and strand lots of developers in 2008. That they even published a PEP stating there will be no Python 2.8 is silly and mean.

To end on a hopeful note: Why won't someone make a Kickstarter... if you manage to get full support for loading Python 2 modules into the current, main CPython 3 codebase (upstream), I'd be willing to pay, say, 100€. I'm sure some companies with legacy codebases would like to chip in.

What is a major open source project that is Python 2 only?

Ansible.

Parts of Twisted. But open source projects are not the problem. We (a major scientific collaboration) have likely millions of lines of Python (2). Mostly used in one-off plotting scripts, or as configuration or steering files.

On the one hand, I bet >95% of these scripts translate perfectly with 2to3.py, have no unicode/str confusion issues, and would be trivial to port. It's often really just the "print". On the other hand, most of this is "legacy" code, and there is no benefit to port it - we'd rather not mess with code that is supposed to be "frozen" and e.g. able to reproduce past scientific results, and nobody will spend time porting it without tangible benefits.

Last I checked, it was considered "too hard" to move to Python3, but in the meantime we are switching VCS (from SVN(!) to git), we are rewriting our main framework to be multithread-capable, and tackling a bunch of other gargantuan tasks. So if going to Python3 is harder than all that, then I think something went wrong with the transition. (For the record, for personal projects I use Python3 now, as everything has catched up for me.)

Spoken like someone who's never maintained a M+ line monolithic codebase.

Of course you should upgrade, but an armchair admonishment that papers over the actual costs is just a lot of hot air.

^This

> If you’re on the older version (“Python 2” as you say), you’re a decade behind, you should have upgraded at 2008.

Ok, I've stopped reading there.

Python Community Still Unwilling to Learn from Mistakes Made in Python 3 Transition

> If you’re on the older version (“Python 2” as you say), you’re a decade behind, you should have upgraded at 2008.

NumPy didn't support Python 3 until release 1.5.0, which came out 2010-08-01.

SciPy didn't support Python 3 until 0.9.0, which came out 2010-12-12.

PyCrypto got Python 3 support in late 2011.

Those three alone made switching to Python 3 in 2008 completely unfeasible for a heck of a lot of people.

That was one thing the PHP community got right with the upgrade to PHP7: they made sure the major frameworks and libraries worked well from the start - and worked "better" in the new version (in this case they got a free performance boost).

It's not the same language. This blog post is flaimbait with zero useful information. Thanks.

It starts out saying that it's all the same language, then it veers wildly off course to talk about how different they are in saying that Python 3 is way better. Facts are only concrete if and when they are useful.

Wonderful.

2008. Right. When there was NO library support and major performance issues. Get real. Garbage article.

Reply on news.ycombinator.com