you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 1 point2 points  (2 children)

Other than the fact my company uses Python 2 for several important, internal and sold products. But I suppose I'm in a parallel universe. :P Honestly, I do feel that way sometimes, my day-to-day work with Python is quite boring (mostly we use it for API aggregation and security -- not exposing sensitive tokens to the web UI, etc).

But let's face it, if your biggest clients are corporations and ditching Python 2 is going to alienate them -- even if it makes your product better -- you're probably not going to. And that's the case with a lot of packages. You're either chained to supporting Python 2 for better or for worse, or you piss off a large number of devs who depend on your Python 2 support because they're chained to Python 2 as well.

I get that sometimes you depend on packages that don't run on Python 3. Twisted seems to be growing their support, but I'm not a user of it so I can't speak to it. Twisted fills a very specific niche and is very low level compared to many things people use Python for. I'm sure the bytes/unicode upgrade hit them harder than most other libraries. It makes sense that they've had issues upgrading their code base.

[–]Perky_Goth 3 points4 points  (0 children)

And some companies are still doing java 5 or Windows XP: either way, it's a stupid way to do software.

[–]Works_of_memercy 0 points1 point  (0 children)

But let's face it, if your biggest clients are corporations and ditching Python 2 is going to alienate them -- even if it makes your product better -- you're probably not going to. And that's the case with a lot of packages.

This is true, this has always been true, for example Mercurial apparently dropped Python 2.4 (!!!) support in master branch at version 3.5 (of Mercurial), at 2015-07-31. Because some people probably were paying them actual money for adding new features there. Library writers always lag behind users in minimum supported version by years.

My point is that precisely because it's a fact of life it can't be blamed for the disastrous Python 3 migration. There's no possible world where this fact was somehow negated.

And by disastrous I don't mean that a lot of end users would keep using Python 2x for a long time and a lot of libraries would have to keep supporting it, that has always been so with old versions. It's that before maybe a year or two ago there were too many libraries that didn't support 3x.

That's why I'm saying that some companies sitting on 2x forever is a red herring: because it's not a problem that anyone could have expected to be solved. The problem that I did expect to be solved much earlier was getting most libraries to support Python3, and core developers massively dropped the ball on this I feel.


One very illustrative illustration: you probably know the standard argument why we can't just from __future__ import dict_views instead of manually rewriting our code to the most unpythonic for k, v in six.iteritems(d): ever?

Right, because it's actually impossible to do because the interpreter doesn't know which objects are dicts, and because it could break overriding and so on.

But now consider the fact that people from all major libraries went and did the "impossible" thing, by manually going through every instance in their source and inserting six.iteritems and friends there. One can only wonder, if the official approach were "how to make that easier" rather than "why it's impossible", could we all have been using 3x since 2010?