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

[Donald Stufft]

> 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