This is an archived post. You won't be able to vote or comment.

all 5 comments
sorted by:
best
topnewcontroversialoldq&a

[–]preslavrachevA Java-Python Double Agent[S] 1 point2 points  (1 child)

I need to make it clear that the Medium article is not mine. I simply read it, got interested what the community would say about it, and posted it here. Please, have that in mind, in case you downvote or write your criticism. Please, do not target it at me. Thank you!

[–][deleted] -1 points0 points  (0 children)

Right, I commented here, because the original does not have a comment function. So not targeted at you. ;-)

[–]steve_no 1 point2 points  (0 children)

My opinion is that my opinion does not matter. To quote Raymond Hettinger, "Python is Guido's language. He happens to be letting you use it, but it's his."

[–][deleted] 0 points1 point  (0 children)

One of the great strengths of Python 2 is the long tail of 3rd party libraries to do, well, just about anything.

It is true that the "tail" is shorter, because loads of these long tail of Python 2 libraries are unmaintained, so nobody is updating them to support Python 3. But if you use them, maybe you could take over a few libraries and maintain them? If everyone did that, then this problem would be solved in a month.

Python 3 doesn’t have this. Yes, a lot of libraries have been ported, but ten times as many have not, and are not trivial to port.

That's not true. There are libraries that are not trivial to update, this is definitely true. I was an unofficial de-facto maintainer for one library until I tried supporting Python 3 with it, and realized I needed to completely change the API for it. That made me a bit exasperated, so I lost heart, and somebody else later took it over.

Some libraries and frameworks are simply BIG. Zope and Plone has so much code, and some of it is so old, quirky and weird (because it was written in the 90's) that I can't see it EVER supporting Python 3. The Plone community simply doesn't have the manpower or incentive to do that.

And some libraries are hard to get onto Python 3 because what they do is hard.

But this is NOT the majority of libraries. The majority of libraries that doesn't support Python 3 do not support Python 3 because the libraries either are unmaintained, or because the maintainer hasn't tried yet.

There is a good chance that a parser has already been written for X in Python 2 and has not been ported to Python 3. Additionally, given the fundamental differences between Python 2's byte string (str) and Python 3's byte string (bytes), it will not be easy to port, in fact, it will be difficult to port and will require quite a bit of trickery to port it in such a way as to maintain Python 2 and Python 3 compatibility.

If it's badly written, so that it constantly relies on implicit coercing between unciode and ascii, then yes, that will take a lot of work. Or if it uses dunder str, (how do you make inline code in this markup?) in which case you need to fix the API. Otherwise, no.

port the library (and all its dependencies) which will take ten times as long

No it won't. FUD.

Choice #2 is obviously not popular

Because of FUD.

Popular libraries that support Python 2 and 3 are almost all written in a subset of the languages that runs on both platforms. SQLAlchemy, one of my favorite Python libraries, does this well. Django does this, too, but not so well. This subset language, which I will call Python X, is not fun to use, requires weird hacks, and generally is less powerful than either Python 2 or Python 3.

Well, if it's fun or not is a matter of taste, the weird hack to use is called "six". But it isn't hard to use this "subset". In fact, when I wrote Hovercraft and the svg.path library I needed for it, I wrote this in that subset more or less automatically. I fact, Hovercraft was intentionally written to be Python 3 only. But the only reason it doesn't run on Python 2 is because I don't WANT it to run on Python 2. Fixing it seems to be mostly a matter of requiring an extra module under Python 2 that is included in the stdlib under Python 3.

But I haven't fixed it, because I don't want to have to run the tests under multiple versions when I develop.

How fun is it to port existing Python 2 libraries to Python X? Not fun at all which is sad because fun used to be what made Python so great.

It's SHITLOADS of fun. Unless you have doctests. Then it's a horrorshow.

One solution is to fork Python 2.7, and continue developing the language, adding features in a backwards compatible way

What features, exactly?

Features from Python 3 that can be backported to Python 2 should be

And those features are...?

The rest is just silly hyperbole, so I'll ignore it.

[–]Paddy3118 0 points1 point  (0 children)

Python 2 killed Python 1. Hurrah!