I picked up Python about 1 year ago as my hobby language, and following the common advice, I started with 3. But I quickly encounter two problems:

1) some libraries I actually wanted to use were still 2

2) When I tried to google a solution for something, more than once I stumbled across a code which just didn't work. Then it occurred to me, that this is because the example is Python 2, while I am on 3.

To sum it up, I later switched to 2, and everything was fine since then. I also asked my friend, who is a professional python programmer, and to this day his company still uses 2 and don't plan to switch.

> 1) some libraries I actually wanted to use were still 2

For anyone still in this situation, re-evaluate them - that issue is mostly solved.

Python 2 is deprecated. It's no longer supported after 2020. There's no point in using it for new projects, unless there's a very good reason. You're missing out on lots of incredibly cool features like asyncio and static type checking.

There's even an increasing number of Python 3-only libraries.

Can you elaborate on static type checking? Is this the type hinting a.k.a type annotations outlined in PEP 0484 or something else? What is this even useful for? Better documentation or integration with an IDE like PyCharm?

I think he's talking about PEP 0484. As I understand it they go into separate files and there is a gradual typing system. The inspiration came from mypy http://mypy-lang.org/ and the point is mainly for IDEs and convenience in development currently, though they could be used for optimizations in implementations other than the reference interpreter.

This seems like your mental model assumes relatively small codebases. On a codebase with 1m LOC, your estimation of 2500 lines/day still takes ~400 person-days. That's a big investment to put into something that doesn't present clear benefits. Moreover, converting a huge codebase piecemeal is something of a challenge; I don't know if it's even possible to have python 2 importing python 3 (or vice versa) but assuming your large codebase is relatively interdependent, reorganizing the codebase such that you can split it into modules which can be migrated independently could also be a big undertaking. I would also anticipate that there would be a long tail of fixing bugs caused by incorrect migration (are we code reviewing those 2500 lines/day?) as well as lower productivity as developers get used to the new language.

This is why you frequently hear that large, established codebases that control their environment aren't updating to Python 3. It's pretty easy to move a few thousand lines over but complexity scales non-linearly with the size of the codebase.

It's libraries rather than porting.

Funnily, though, I just thought 'yeah there's that library I use, they never ported that', for one of my codebases. Just looked it up and they now have ported it. So I guess it's time for me to do the same. I wonder what proportion of (actually used) libs are Py 2 only still.

At this point very few 'actually used' (meaning, used by more than a handful of organizations at most) are Py2 only. There are a few still in the process of porting, and a few that will never be ported due to being replaced (but are still somewhat popular for one reason or another.)

For those who don't know: http://python3wos.appspot.com/

People are still releasing brand-new Py2-only libraries to this very day. This is especially true in science, math, nlp, ml, etc.

Yes, and I kinda think it is silly, but whatever. Care to share any examples of recent releases? I know Google's TensorFlow was/is Py2 only, but a Py3 release is imminent. Google has an unfortunate habit of using Py2... I can understand they have their reasons... it is a bit irritating though :)

(Edit: Not that I care what they use internally... but sometimes they release a really cool open source library and it is Py2 only... arr! But at least they are sharing, so I can't really be too upset :)

snap-python. Development started in 2013, and yet they refuse to support Python 3: https://github.com/snap-stanford/snap-python/issues/52

So you'll have to convince them. Maybe they did not realize that SWIG supports Python 3 nowadays?

There's really no good reason not to support Python 3, and projects which refuse will at some point be forked.

Nah, just do the smart thing and stick with python 2.7.

Such as....

The entire scipy stack, ntlk, tensorflow has partial 3.0 support and plans to support both, caffe, theano, etc.

There are few to no libraries that don't support, or don't plan to soon support both.

I thought you were listing examples of libraries that didn't support Py3... so I was gathering links to refute your claims... then I realized you were posting examples in support of my claim that Py3 support is the norm :)

TensorFlow?

Python 3 support is literally issue #1: https://github.com/tensorflow/tensorflow/issues/1

I suspect this is just an issue of they didn't want to block the release on not having Python 3 support ready at launch.

The weird thing as a non-python user is why did they even start with python 2 as first class in mind?

Probably the same reason (or at least somewhat related to) that Google App Engine only supports python 2.7. (https://cloud.google.com/appengine/docs/python/)

Python 2 is used internally at Google, and TensorFlow is, I believe, an open sourcing and nicer packaging of something that has already existed internally for awhile.

Big companies are moving slow, even Google.

because the low risk, high-audience strategy, when you're launching a new product, is to follow the path of least resistance, rather than being dogmatic. Maximum audience.

It's easy to port to python 3 but I think the holdup with some libraries is that they want to support both 2 and 3 with the same library so that devs who cannot upgrade the python on their system don't get left behind. Supporting both at the same time is possible but takes longer in most cases.

I just read the http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/ article referenced elsewhere in this discussion and it illustrates why there is some stuff that is not so easy to port.

Most servers are probably still running on Python 2.6 and 2.7.

Between virtualenvs, containers, or just plain ol' `make altinstall`, there are enough ways to run a python application that _doesn't_ use the system python interpreter that this shouldn't be an issue. Not to mention that most linux distros have packages set up in a way to allow python 2 and python 3 to be installed simultaneously, without interfering with system applications that rely on the version of python that is shipped with the OS.