Given that even a relatively inexperienced developer can easily port 2,500+ lines of Python 2 to Python 3 per day, there's really very little reason for anyone to still be on Python 2 regardless of the benefits or lack thereof of Python 3. This is especially true if you're not trying to take advantage of all the performance benefits of Python 3 right away, and are content just to wrap iterators in list() or whatever just to get the functionality working the same without much effort.
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.
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.)
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 :)
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 :)
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.
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.
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.
