> On Dec 13, 2014, at 12:29 AM, Donald Stufft <don...@stufft.io> wrote: > >> >> On Dec 12, 2014, at 11:55 PM, Steven D'Aprano <st...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
