[Python-Dev] Python 2.x and 3.x use survey, 2014 edition

Donald Stufft donald at stufft.io
Sat Dec 13 06:29:39 CET 2014


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

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



More information about the Python-Dev mailing list