[Python-Dev] Python 2.x and 3.x use survey, 2014 edition (original) (raw)

Donald Stufft donald at stufft.io
Sat Dec 13 06:38:24 CET 2014

On Dec 13, 2014, at 12:29 AM, Donald Stufft <donald at stufft.io> wrote:

On Dec 12, 2014, at 11:55 PM, Steven D'Aprano <steve at pearwood.info> wrote: On Fri, Dec 12, 2014 at 10:24:15AM -0800, Mark Roberts wrote: So, I'm more than aware of how to write Python 2/3 compatible code. I've ported 10-20 libraries to Python 3 and write Python 2/3 compatible code at work. I'm also aware of how much writing 2/3 compatible code makes me hate Python as a language. I'm surprised by the strength of feeling there. Most of the code I write supports 2.4+, with the exception of 3.0 where I say "it should work, but if it doesn't, I don't care". I'll be very happy when I can drop support for 2.4, but with very few exceptions I have not found many major problems supporting both 2.7 and 3.3+ in the one code-base, and nothing I couldn't work around (sometimes by just dropping support for a specific feature in certain versions). I'm not disputing that your experiences are valid, but I am curious what specific issues you have come across and wondering if there are things which 3.5 can include to ease that transition. E.g. 3.3 re-added support for u'' syntax. For what it’s worth, I almost exclusively write 2/3 compatible code (and that’s with the “easy” subset of 2.6+ and either 3.2+ or 3.3+) and doing so does make the language far less fun for me than when I was writing 2.x only code. I’ve though a lot about why that is, because it’s certainly not hard to do so, and what I think it is for me at least is inherient in the fact you're using a lowest common denominator approach to programming. Because I can only use things which work the same in 2.6+ and 3.2+ it means I cannot take advantage of any new features unless they are available as a backport. Now this is always true of code that needs to straddle multiple versions in order to maintain compatability. However the way it "used" to work is that the newest version, with all the new features, would quickly become the dominant version within a year or two. The older versions might still command a respectable amount of use, but that tended to fall off quicker and it wouldn't be unreasonable to be more aggresive in some situations than others depending on what the new feature was I wanted to use. However when we look at today, the "new" versions are Python 3.4, 3.3, or even 3.2. However I can't really justify for most situations supporting only those things because even today they are not the dominant version (or really close to it in any number I have access too). This means that if I want to take advantage of something newer I'm essentially dropping the largest part of the ecosystem. On top of all of this, I'm not sure I see a point in the near future where this tipping point might happen and the "normal" order of the newest version with the newest features rapidly becoming the dominant version gets restored. I'm sort of holding out hope that the Linux distribution switching to Python 3 as a default might push it over, but I'm also not holding my breath there. So that's basically it, lowest common demoniator programming where it's hard to look at the future and see anything but the same (or similar) language subset that I'm currently using. This is especially frustrating when you see other languages doing cool and interesting new things and it feels like we're stuck with what we had in 2008 or 2010.

Oh yea, in addition to this, actually backporting things is becoming increasingly harder the further Python 3 gets developed. When the language was mostly forwards compatible if a new feature/function was added you could often times backport it into your own code in a compat shim by simply copy/pasting the code. However with all the new features being done in Python 3, it's increasingly the case that this code will not run on Python 2.6 and 2.7 because it's essentially being written for a different, but similar, language and requires some amount of porting. This porting process might even need to include incompatible changes because of differences in the language (see for example, Trollius).

Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

More information about the Python-Dev mailing list