> > but I also don't envy the folks who have to wrangle with P3.

> What wrangling is there?

Every time a PEP modifies the syntax or semantics (e.g. ordered dicts for class namespaces) any project that wants to conform to Python 3 has to "wrangle" those changes into their thing. There are more Pythons than the C Python, not to mention tools like Snakefood[1]. That's in addition to "wrangling" with new bugs introduced into the interpreter while adding support for new features, and with the new sources of bugs that the new features and syntax enable.

A stable unchanging Python 2 doesn't engender any of that overhead. You just have to fix bugs and security, uh, bugs.

> > All I'm really saying is, if you think of P3 as a separate project, and pretend that P2's wind-down is just a coincidence

> This is an unhelpful comparison.

Unhelpful to whom? I'm trying to explain my reasoning around sticking to Python 2 and that's how I look at it. It doesn't matter to me that the BDFL is the one pushing this, as much as I like him he's not an actual dictator. He's pissing in my soup and I don't mind saying so. (Yes, he made the soup in the first place but some of it's in my bowl now and he can't have it back.)

> The same thing is true for approximately any feature for any open source project. Would a fork of go which adds generics take mindshare despite being "better"? No! (such forks exist). But that doesn't preclude the official Go implementation from adding generics.

I don't understand. P3 isn't a fork which adds a few features, that's Tauthon. P3 is a different language that's almost-but-not-quite Python 2.

I'm not saying Python 3 shouldn't exist, that's a separate argument I'm not making. What I'm saying is given a choice between stable Python 2 with a decaying maintenance cost and Python 3 with its open-ended maintenance cost and no compelling technical reasons to adopt it, well, I'm sticking with 2.

> > The incompatibility was a choice, and I think it's the wrong choice.

> I'll repeat that most of the code that I write is python3.6 and python2.7 compatible. The only incompatibilities are things that are essentially bugs in python2/not fully specified (unicode vs. string handling), and then a bunch of additional features. It took me all of 3 hours to port a relatively meaty python2.6 application to being 3.6 and 2.7 compatible (and it was a hell of string + unicode nonsense). All it requires is good tests and some dedication, and porting is really, really easy. People just don't seem to believe that.

You're not wrong, I've done it too. But all I got out of it was Python 3 compatibility... So far your best argument for conversion is "people will support it" and I keep telling you "people will support Python 2 too".

But the incompatibility I'm referring to there is the one I mention in the preceding sentence: "a better way of going about the whole thing would have been to have the P3 interpreter support P2 code and let conversion to 3 be driven by its merits." The Python 3 interpreter should run Python 2 as well. That's the "choice" I think was wrong.

> Worst case for you: twisted begins to support asyncio and rely on python's own event loop. Then twisted code magically gets async/await support in python3 and backporting features becomes potentially impossible.

That actually made me laugh out loud. Cheers. But that still wouldn't break their existing code. And again, I wouldn't use Python for [cutting edge] networking. I've done it. It's good for prototypes.

Look, maybe there will come a day when there's some P3 lib I just have to use in one of my projects and it's somehow just so stitched into the Python 3 that I can't backport it or imitate its magic in Good Ol' Two. If that day comes, well, "porting is really, really easy". ;-)

(It's been really fun discussing this with you today. Cheers and warm regards!)

[1] "snakefood: Python Dependency Graphs" http://www.furius.ca/snakefood/