[naftaliharris]

Original author here. I built this a few years ago, and the main motivation at the time was that I'd heard people say that adding the new features in Python3 required breaking backwards compatibility, which I didn't believe. IMO the only feature that really required breaking backwards compatibility was the str/unicode consolidation and refactoring. This project was my way of proving that we could have gotten the other features that people tend to be most excited about (async/await, function annotations, new super(), etc) without breaking existing Python2 code. I think it was successful at that as a proof of concept.

It was a fun project; I learned a lot about how the CPython implementation works and have a lot of respect for the people that built it. It was surprisingly easy to implement Tauthon based off the work the core dev team did on Python3: https://www.naftaliharris.com/blog/nonlocal/

For what it's worth, I do believe that Python3 is a better language than Python2. We use Python 3.7 at my work (SentiLink) and we've had a good experience with it. (If you're starting a new project or can migrate, I'd recommend it). But I do think that the ~10 year saga of upgrading to Python3 from Python2 wasn't necessary when the main benefit was really the unicode refactoring.

I no longer maintain Tauthon personally but there are others who are excited about the project who occasionally add new features or bugfixes.

[baq]

meanwhile exceptions just sob in a corner, forgotten.

the main benefit is actually sane exceptions. unicode is nice and all (i'm a native speaker of a non-english language) but it's a storm in a teacup IME.

[alfalfasprout]

First off, cool project Naftali! One of the issues that ultimately became more common as Python2 became EOL is that a lot of libraries began to release only wheels for Python 3.x variants. When there's C/C++ extensions this means that even running a compatible fork wouldn't suffice.

Do you think it would have been feasible to make wheels compiled against the python 3.x C APIs also compatible with Tauthon?

[takeda]

I don't know what it supposed to prove. It was no secret that Unicode was what broke compatibility, the other changes were there to use that as an opportunity to fix warts that accumulated over years (like organization of system packages, print statement, division, classes etc. I don't believe Thauton fixed these things though)

It was no secret that everything else was portable, that's essentially all what python 2.7 was - backporting 3.x features to Python 2. It was a waste of resources for developers to maintain 2 forks of Python so that effort was stopped in 2015. There was 5 extra years to move application to Python 3.

5 years is frigging long time in computer terms, and your project felt still like giving f-you to the core developers for trying to improve the language. Trying to call the project Python 2.8 was very aggressive and would create a lot of confusion if Guido would accept that.

I'm glad you gave python 3 a try, I feel like the people that were against it didn't write any new application in it, and their experience was porting Python 2 code to 3. It can be very frustrating when Python 3 complains about bugs that Python 2 just ignored, but if you write a python 3 application from scratch you don't even notice the Unicode, and that was the goal.

[ehsankia]

Some of the changes I feel were a step too far though. Completely removing iter{items,values,keys} just made the migration so much more painful. I would say I spend a significant amount of time figuring out if I want to rely on six or if the array is small enough that I can live with unoptimal .items() in py2 throughout the migration. What would've been the issue of keeping .iter*() calls around, with a warning maybe? In general, there's a lot of stuff that could've been kept for backward compatibility, with a warning. It's much easier to slowly fix issues like that over time as you maintain code than to have to convert it all in one go, which put a giant barrier for people want to switch.

[takeda]

pylint --py3k found many of these, and mypy the rest (granted you had to specify proper types)

But I agree, the warning would be a good idea.

[toyg]

I feel a bit like you’re trying to rewrite history here.

When you launched it, you called it “Python 2.8”. You posted it everywhere to gain traction, and didn’t rename it until the PSF and Guido got you by the ear, so to speak. There was no mention of “everything but str” or whatever, as far as I recall.

It was an outright (and hostile) attempt to fork - something that, going by your words here, I guess you now recognise as a mistake. I guess saying “I screwed up” is hard.

[fao_]

Can you provide citations for your claims? The commentary in the github renaming issue from 2016(0) seems pretty jovial and has the tone of "oh, actually we should change that, oops" rather than "we WILL replace python!". The comments by guido and harris reinforce this perspective:

    > gvanrossum commented on Dec 10, 2016
    > Since I was asked: The project's name (and its binary name) need to 
    > change. They are misleading. The rest looks acceptable according to 
    > Python's license. This is not an endorsement (far from it).

    > naftaliharris commented on Dec 10, 2016
    > I don't mind renaming this project. Any other suggestions for good 
    > names? I personally like "Pythonesque (/usr/bin/pesque)" the best so 
    > far, thanks @dbohdan! :-)
    >
    > @VanL, not that I'm necessarily picking that, but would a name like
    > that be acceptable?

When you're in a community or a space, actions that are unintentionally hostile towards that community or space, can be seen as intentionally hostile by the members, and if you only hear about it second-hand, or you spend a lot of time around the group, that belief can be reinforced through the discussions and gripes the group has about it(1).

(0): https://github.com/naftaliharris/tauthon/issues/47 (1): That's not to say there aren't bona fide intentionally hostile actions that happen, but rather that's how actions that aren't intended to be hostile can be remembered and percieved as such.

[toyg]

It was all very disingenuous. It was obvious to everyone, after 8 years of flames, that such a move would have been incendiary. Naftali played dumb only after he was called out on it.

I'm not saying it was entirely his fault - certain widely-heard voices in the community had been advocating for this to happen, in practice, for several months; he saw an opportunity and went for it. I just object to the rewrite of history to justify the mistakes of the past.

[fao_]

> It was all very disingenuous. It was obvious to everyone, after 8 years of flames, that such a move would have been incendiary. Naftali played dumb only after he was called out on it.

Have you considered that not everyone who forks something participates in the original community?

> I just object to the rewrite of history to justify the mistakes of the past.

So far there has been no evidence for the stated claim, just supposition and rumour. So as-is there's no reason for anyone here to believe that "history is being rewritten" aside from easily-mistaken word of mouth.

These days most discussions over the internet happen via the written word, so it's difficult to believe that you can't find records from IRC, Github, or Email to support your contention that it was hostile.

[loeg]

You're coloring the history with a lot more hostility than the reality. And the condescension is really unnecessary.

This matches the pattern of Python.org developers and python 3 aficionados being unnecessarily hostile and condescending to the concerns of Python 2 language users. You saw that in 2010; you saw it again in 2015; and you can see it in these threads today.

[joshuamorton]

Can you explain the specific actions that were taken that didn't cater to, as you say, "python2 language users"? A 12 year migration timeline seems, to me, to be fairly lax.

[strenholme]

I saw a lot of hostility right here in 2019 when I pointed out some Python 2 programs are nay to impossible to port to Python 2: https://news.ycombinator.com/item?id=21258527

[joshuamorton]

None of the things you mentioned are particularly difficult though. In fact you're still in the realm of changes that can be trivially automated with https://python-modernize.readthedocs.io/en/latest/fixers.htm..., the three issues you describe are the print, xrange_six, and classic_division fixers.

It's certainly possible that there are parts of the migration that would be tricky, a quick skim of the file didn't give me any obvious ones, but it's also huge and hard to read, so I very well could have missed something.

Most of the truly challenging things to migrate involved some combination of extension modules, heavy metaprogramming (eval/exec), and apis which change significantly between 2 and 3 (most of which are string related, but some libraries also decided to do backwards incompatible things)

[talentedcoin]

I am definitely guilty of being "hostile and condescending" to people asking the Python.org developers to waste time supporting Python 2. Please just stop. This time would be better spent working on the packaging situation rather than relitigating the last 12 years.

If people still want to work on Python 2 projects that's fine and it's their choice, but it's time to just let the rest of us go our own way.

[tyrust]

Context, since I had never heard of this:

   * https://news.ycombinator.com/item?id=13144713

   * https://github.com/naftaliharris/tauthon/issues/47#issuecomment-277081725

[behindsight]

Thanks, I appreciate the context links

(friendly note: code blocks break clickable links)

1: https://news.ycombinator.com/item?id=13144713

2: https://github.com/naftaliharris/tauthon/issues/47#issuecomm...

[dang]

Also https://news.ycombinator.com/item?id=13453410

[tyrust]

Doh, thanks!

[lioeters]

I wouldn't call it a "hostile" fork. Imagine what motivated him to fork in the first place. He and many others were between a rock and a hard place, and a fork was a possible way out.

At the time, the author stated:

> I picked [the name "Python 2.8"] initially since when talking with friends about this project it conveyed pretty darn immediately what the project is and does. I'd be very keen to hear people's suggestions for alternate names!

This was no mistake or screw up at all. In fact, the project served his purpose for the time, and even though he's moved on, there are others who like it enough to maintain or improve it.

A fork is (or can be) a healthy, natural thing that happens.

[Ensorceled]

Do you have any references that support the level of invective you are displaying? I feel you are projecting a great deal of ill will on the original author that I, personally, didn't feel or see.

[u801e]

As a general question, why is forking a project perceived as hostile? I always thought that forking an open source project was something that was encouraged if one's proposed contributions were not incorporated into the original project.

[unixhero]

Let's go easy on the ad hominems here.

[strenholme]

I think there is some demand for legacy Python 2 to be maintained, even if the maintenance is limited only to security fixes, and I think it would be good if some company paid you or someone else a full time salary to continue maintaining this Python 2 fork.

It’s a tragedy of the commons: A lot of companies making good money are still using Python 2, but none of them are willing to pay programmers to maintain an open source currently maintained Python 2 fork.

[int_19h]

ActiveState is offering commercial support for Python 2, for those who need it. But places that are so conservative as to need it, are also precisely the ones that will want vanilla Python rather than a fork.

https://www.activestate.com/products/python/python-2-7/

[sandGorgon]

Cool project!