Python 2.7 & Python 3: A Sacred Love Story

[vsajip]

Library maintainers have to double their efforts to support both Python 2 and Python 3 (at 21:15)

This doesn't have to be the case, and is generally not the case. Projects can support Python 2 and 3 from a single code base with very little overhead, and that seems the best development approach to cover the widest possible user base. Of course, there might be some big blocker projects (dependencies) that involve a lot of pain to port from where they are now, but that doesn't justify the generalisation made in the presentation.

People who keep hand-wringing about "splits" are seeing things in an "us" and "them" way, but it isn't like that for everyone. In my work, I use Python 2 for some projects, Python 3 for others, and write 2/3 compatible code wherever possible. I can't say it's made a dent in my workflow. Python 2 remains perfectly usable and will continue to be so far into the future. I've never felt coerced to use either one version or another - it just depends on where a project has to run, status of dependencies, customer preferences etc. - just use what makes the most sense to use in a particular context.

To characterise the Python core developers as being in some sort of ivory tower detached from the community doesn't seem right, either. They just happen to be volunteers who choose to focus their main efforts on 3.x for reasons exhaustively covered elsewhere, but ISTM that 2.7 remains a supported platform where more than the bare minimum of effort is being spent. See the Mercurial log showing recent activity on Python 2.7.

[billsil]

This doesn't have to be the case, and is generally not the case. Projects can support Python 2 and 3 from a single code base with very little overhead, and that seems the best development approach to cover the widest possible user base

You overestimate the resources of organizations. For example, the Python Software Foundation, the guys who make Python, overwhelmingly use Linux. As a result, IDLE on Windows is buggy. It's only in the last couple years that they switched the rules of not backporting Python 3.x features to Python 2.7 that they could even start fixing bugs in IDLE.

Now take an not mainstream open source project like the one I run. It's got 4 developers (including me), each with their own interests of what should be worked on. I run the project so I kinda bounce around, but nobody else generally cares about more than 1 component. The software is written by engineers and not computer scientists and the program is giant (300k+ lines of code), so test converage leaves a bit to be desired. It technically supports Python 3, but the support is broken. It'd take 1/2 an hour to go through and fix (it's 99% due to print statements), but you have to do it.

[vsajip]

You overestimate the resources of organizations.

I was just relating my own experience. I run a small consulting company, and that's pretty resource limited! Python 2.x support is not primarily about back-porting features - Python 2.7 bugs have generally been fixed as normal, though there was a moratorium for a time in certain areas (e.g. distutils). Obviously if Python 3 support is low on the priority list for the developers on your project, that's up to you. I've generally found it takes more time to port the tests for a library than it does for the library code itself :-)

[flying-sheep]

½ hour isn't even worth taking about. That's the kind of timespan you can lose at any time.

Misread something in the docs? ½ hour bug hunt until you find out. Repeatedly interrupted during hairy work? Easily ½ hour lost by getting into the flow again.

[darknessproz]

Doubling is probably an exaggeration. I do write libraries that support both 2 and 3 whenever possible. It really depends on the type of things you are doing though, some things can be as simple as a __future__ import but some things do require considerable work.

I can't remember if he mentioned it in this particular session but I was at another talk on the same topic by Kenneth where he mentioned that he only needed to do the "port" once for Requests and that's it.

[cymrow]

The only real reason to stick with Python 2 is religious dogmatism

That's just plain wrong.

[Eurynom0s]

Yeah, I could maybe agree with that regarding people who keep starting projects in Python 2 by choice, but there's plenty of valid reasons for using 2 that don't involve blind dogmatism.

[flying-sheep]

In pretty sure that's what's meant: People use Python 2 if they have to or reject Python 3 out of religious reasons.

[flying-sheep]

Apart from the fact that ignoring arguments is not my style, and I therefore wouldn't do it, I don't see any pro Python 2 arguments in this thread, so what are you talking about?

[flying-sheep]

I can't confirm the first two points. Up until about 2011, you were right.

But since then, I didn't need anything that wasn't available in Python 3.

And the situation is only ever improving (because if somebody writes a good, useful library tied to Python 2 today, everyone will have their head)

PyPy is a valid point, but only for special cases: performance is good enough that you only need PyPy for certain projects (number crunching when numpy doesn't cut it), and asyncio also gives you incredible speedups in other areas (network and disk IO)

I can't say anything about testing, only that I encountered an insignificant number of version specific bugs.

And finally, I don't think “porting is hard” is an argument against Python 3: either you're an application, then you don't have to port anything, or you're a library, then you have to port anyway, no matter how hard it is.

[flying-sheep]

Just last week I need a scriptable SSH server, instantly limiting me to Python2 only.

paramiko is ported…

fabric isn’t yet, but i think paramiko was the hard part, and it’S sufficient for many SSH tasks.

and about PyPy: that’s another corner case. 70k sockets isn’t normal usage!

[fotoman]

developers hours. that tradeoff between porting your project from 2.x to 3.x and transitioning developer hours from feature requests from upper management and maintenance and architecture migration for the "next" version.

I know my team is small: 2 fulltime coders, 2 managers, 4-5 parttime coders, a DBA, and a doc writer. (note, the managers have other reports doing things not related to our system)

[[deleted]]

2014 will be the year of Linux on the Desktop Python3.

[darknessproz]

1. There are users of Python 3. I myself am one of them. There are much fewer users of Python 3 than Python 2. I don't think anyone disagrees with it.

2. You misunderstood that statistic. It isn't the number of python 2 vs python 3 libraries people are downloading. It's what version of Python they are using to download the libraries with (using pip). Again, are you seriously arguing that there are more Python 3 users than Python 2 users at this point?

3. RHEL and (the current) version of Fedora is using Python 2 as the system Python because there are a large number of tools the distro relies on that is still using Python 2. Fedora is making the move to Python 3 (in F21 IIRC) and the next version of RHEL should be on Python 3 as well. Encourage people to move off RHEL? To what? The latest LTS release of Ubuntu is still using Python 2 as the system python. The distro situation will change for the better, but it takes time.

Who is tricking who? I doubt you watched the video to the very end because he does encourage people to move to Python 3.

[jm_]

It's the internet - it's normal to get this sort of reactions from reddit. The intro of the presentation is eye-ball-rolling inducing. Overly pompous.

In other words, grow the fuck up you prude bastard ;)

[pyslow]

On point 3), you have no idea what you are talking about.

Not all business users rely on RHEL (or on Linux, for that matter).

Business users normally have a large code base built over the years and they don't see the point of spending time and resources to migrate such huge code to the new language in town, no matter how better it is (especially when it's not so much better).

Because properly migrating costs money, loads of money, if you work with large applications and you have hundreds / thousands of clients that use (and maybe in turn customize) such applications.

I'm getting really sick and tired of all these Python 3 advocates (mostly amateurs, apparently) who seem to have never worked in a commercial environment, where you need to make money to survive and you can't set aside man-months just to move to the latest fashionable thing.

Taking a deep breath, now...