6 ms·

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 re

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/ 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 6y ago
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.
toyg 6y ago
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.
- tyrust 6y ago
  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 6y ago
    Thanks, I appreciate the context links (friendly note: code blocks break clickable links) 1: https://news.ycombinator.com/item?id=13144713 https://news.ycombinator.com/item?id=13144713 2: https://github.com/naftaliharris/tauthon/issues/47#issuecomment-277081725 https://github.com/naftaliharris/tauthon/issues/47#issuecomm...
    - dang 6y ago
      Also https://news.ycombinator.com/item?id=13453410 https://news.ycombinator.com/item?id=13453410
    - tyrust 6y ago
      Doh, thanks!
- loeg 6y ago
  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 6y ago
    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.
  - talentedcoin 6y ago
alfalfasprout 6y ago
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?
sandGorgon 6y ago
Cool project!
strenholme 6y ago
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 6y ago
  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/ https://www.activestate.com/products/python/python-2-7/
takeda 6y ago
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 6y ago
  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 6y ago
    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.

baq 6y ago

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.

toyg 6y ago

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.

tyrust 6y ago
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 6y ago
  Thanks, I appreciate the context links (friendly note: code blocks break clickable links) 1: https://news.ycombinator.com/item?id=13144713 https://news.ycombinator.com/item?id=13144713 2: https://github.com/naftaliharris/tauthon/issues/47#issuecomment-277081725 https://github.com/naftaliharris/tauthon/issues/47#issuecomm...
  - dang 6y ago
    Also https://news.ycombinator.com/item?id=13453410 https://news.ycombinator.com/item?id=13453410
  - tyrust 6y ago
    Doh, thanks!
loeg 6y ago
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 6y ago
  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.
- talentedcoin 6y ago

alfalfasprout 6y ago

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?

sandGorgon 6y ago

Cool project!

strenholme 6y ago

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 6y ago
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/ https://www.activestate.com/products/python/python-2-7/

takeda 6y ago

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 6y ago
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 6y ago
  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.