
It's Python, Not Python 2, Not Python 3 - gh1
https://medium.com/@Alir3z4/its-python-not-python-2-not-python-3-7caeef5adb29#.kecbwl1co
======
lima
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/](http://www.python3statement.org/)

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

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

------
captainmuon
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.

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

~~~
captainmuon
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.)

------
dasil003
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.

~~~
IncRnd
^This

------
schwarze_pest
> 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.

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

------
tzs
> 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.

~~~
omn1
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).

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

------
qeq
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.

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

