11 ms·
Tauthon: Fork of Python 2.7 with new syntax, builtins, libraries from Python 3
- Mave83 7y agoplease get rid of the old python...
- nomel 7y agoJustifying the conversion of a legacy project, that's still being maintained, is very difficult since the conversion doesn't necessarily bring anything tangible, without refactoring, especially if you have fixed dependencies. And, until python 3.7, the conversion would just make everything slower. That's something you never want on your justification list.
- qwerty456127 7y agoThere are many apps written in the old Python nobody is going to rewrite in Python 3 despite many people may need them occasionally. In many cases they can be used for decades as long as there is a compatible interpreter available - there are many contexts where security fixes are not really necessary. There also are platforms where new Python is not and not going to be available, e.g. DOS.
- sevanteri 7y agoBut why?
- ur-whale 7y agoprint with brackets
- michaelmior 7y agoI assume this is sarcasm, but you could do this in Python 2.x already :)
- ehutch79 7y agoThey mean having to use brackets
- unethical_ban 7y agoIn case you look back at this comment, the author has posted in the root of the thread. BLUF: A proof of concept that python3 minus unicode strings could have been done in python2 with relative ease.
- TedDoesntTalk 7y agoWhy would I choose this over python 3? Is it for 2.x legacy code that can’t be upgraded to 3.x?
- coliveira 7y agoMany people dislike Python 3 syntax. I think this is a great project, and given the mishandling of Python2/3, I wish we had a more systematic way to introduce new features. I hope this succeeds.
- ebg13 7y ago> Many people dislike Python 3 syntax Which aspects?
- coliveira 7y agoThe aspect that breaks existing code. They could very well, for example, create a print function that didn't break existing print statement. I think it was a childish move.
- ehutch79 7y agoSO just the print statement then?
- stereo 7y agoThe print statement is also absolutely trivial to fix with 2to3.
- bmelton 7y agoI mean, it was a pretty massive upgrade, and 2to3 exists for those who can't appreciate the value of a a function actually being composable instead of a wrongly-handled statement in the first place. I've worked in and around Python for more than a decade, and I've yet to meet a single developer who didn't initially dig their heels in over `print` being changed, and then later realize that they were flat wrong to have dug their heels in because the new way is measurably better. I mean, I guess I hadn't until today.
- mistrial9 7y agoI will try this - thank you !
- dochtman 7y agoLast commit from 5 months ago. Maybe not a great choice.
- rurban 7y agoStable projects only need bugfixes... Looks very stable to me
- loeg 7y agoShrug. The last commit on the Python.org 2.7 branch was 3 months ago, per the release notes from the other thread today. It wasn't especially active before that. By their own plan, Python.org 2.7's "last commit age" will continue increasing forever. This isn't a great metric for evaluating Python 2 forks, that's all.
- berti 7y agoThe Python.org 2.7 branch is unmaintained so that’s hardly a strong point. That last commit, barring some exceptional circumstance, will be the last ever received by that branch.
- erwinh 7y agoWhy tho
- joshuamorton 7y agoAccording to the open issues, it doesn't currently support `async for`, nor is anything from 3.7 or 3.8 included (dataclasses, f-strings, breakpoint(), a number of performance improvements). There hasn't been a main branch commit since python 2.7.17 was merged in ~6 months ago.
- ltbarcly3 7y agoIt seems like a lot of effort to avoid the parens with print()
- ATsch 7y agoThe bigger porting problem is bytes vs unicode. That can't be done automatically and is a lot of work.
- ltbarcly3 7y agoI guess it seems hard, but if you understand the basics it's just a matter of finding IO and encoding/decoding things appropriately. Python 2 str, unicode and Python 3 str are almost exactly the same as they ever were, and if you are doing binary IO bytes should work as expected. It's not that big of a project, even for a moderately large codebase. If you think you can't get it done in a reasonable period of time feel free to hire me as a contractor and I'll knock it out.
- int_19h 7y agoThe real problem in practice is all the places that relied on implicit bytes <-> unicode conversions. These are also likely to be broken on unusual inputs due to ASCII being the default encoding, rather than user locale... but that kind of thing is depressingly common even so.
- ltbarcly3 7y agothere isn't an implicit bytes/unicode conversion in python2. Do you mean calling unicode('some non unicode string')? That just uses system default encoding. ( sys.setdefaultencoding() ). Just find and replace them and slap in a .decode('UTF-8') or whatever your default encoding was in python2. Grep for the strings encode, decode, unicode and just mechanically fix them one at a time by making the old implicit behavior explicit. How many times could you be doing that anyway? A few hundred? A thousand? You could even script this pretty reliably and just page through the diff you end up with to eyeball them one at a time. I guess you might mean 'str' + u'unicodestr' or something, but again you can find these pretty easily by rooting out where the non-unicode strings are being produced and fixing the problem there. They are either literals or they are coming from IO or calls to str, right? Anyway, I've done this quite a few times and the main concern I've always had was trying to get the patch in place before people commit too much stuff for me to be able to merge the fixed up branch. Of course, you could just do it little by little by taking out places that you are relying on systemdefaultencoding by monkeypatching the default decoding function in sys to log tracebacks whenever it is used, and then whacking them as they come up so you end up with properly handled and explicit unicode decoding before you move away from python2. I bet you could find and fix 95% of the cases in a day of effort.
- berti 7y agoIf you're looking to continue running old codebases without testing and patching this isn't it. There are various incompatibilities with CPython 2.7, some noted in the readme, some noted in issues e.g. [0], and no doubt others unknown. It also doesn't appear to be actively maintained.. [0] https://github.com/naftaliharris/tauthon/issues/22 https://github.com/naftaliharris/tauthon/issues/22
- ehutch79 7y agoIt's too bad the python 3 transition was super short notice and no one had very much time to port their code at all...
- RMPR 7y ago12 years isn't exactly what I will call a super short notice... https://www.python.org/dev/peps/pep-0373/ https://www.python.org/dev/peps/pep-0373/ Edit: I can't find a way to delete this, but I don't think it's fair to be downvoted because I didn't get it was a sarcasm :(
- deleted 7y ago[deleted]
- hackingthenews 7y ago(I think it was sarcasm)
- tomwojcik 7y agoThat was sarcasm
- ehutch79 7y agoCan confirm
- oddlama 7y agoThis is probably what ehutch79 was referring to.
- hackingthenews 7y agoI think we need to recognize that most people/companies who stick to python 2 doesn't do it because they are being stubborn. There is a real judgment call involved. It might look strange from the outside, but maybe it really is daunting to migrate some code-bases to python 3. (I got the sarcasm)
- bigdict 7y agoIs this the most unnecessary project ever? Edit: no, the author built it as a proof of concept.
- naftaliharris 7y agoOriginal 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 7y agomeanwhile 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 7y agoI 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.
- 7y ago
- tengbretson 7y agoWhen are we going to start treating projects that are stuck on Python 2 the same way that we treated IE6 or Adobe Flash? I'm kind of sick of hearing the "well some people have to make technical tradeoffs in what they choose to support" argument. We're all trying to make better software here. Catch up.
- wnoise 7y agoThis just sounds like Python 3 with extra steps.
- KMnO4 7y agoI couldn’t care less about support for libraries and builtins. If my boss came up to me and said “Hey, I think we should use this Python 3.x library”, my response would be “Great, let’s use Python 3”. That said, I understand there are certain applications that are not compatible with 3.x and the company does not have the resources to dedicate to rewriting it. So let’s suppose there is a valid reason someone is forced to use Python 2.7. In that case, the number one priority of this fork should be back porting the security fixes. You can live without async, type-hinting, and f-strings. But please be responsible when it comes to security vulnerabilities.
- mattbillenstein 7y agoI hope this is the last Python2/3 thread we have to endure - I fear it is not.
- gjvc 7y agoIt is possible that the transition from Python 2 to Python 3 is the worst-handled of its kind in the history of open-source so far. Is it any wonder, then, that things like this spring up in their wake?
- cesarb 7y agoI believe the transition from Perl 5 to Perl 6 was worse. (A good overview of it: http://blogs.perl.org/users/ovid/2019/08/is-perl-6-being-renamed.html http://blogs.perl.org/users/ovid/2019/08/is-perl-6-being-ren...)
- paganel 7y agoNot as well-known but still in Python land, I'd also nominate the Zope2 to Zope3 [1] as another such failed transition. [1] https://en.wikipedia.org/wiki/Zope#BlueBream https://en.wikipedia.org/wiki/Zope#BlueBream
- qwerty456127 7y ago> Matrix Multiplication Operator Does this use SIMD instructions?
- bigdict 7y agoYes, if you are using NumPy. But `@` is just syntax. An operator by itself doesn’t “use instructions”.
- MatthewWilkes 7y agoPlease, if you read this and decide it's a great idea, don't start bugging open source maintainers to officially support Tauthon in their projects. The most disruptive voices I've encountered in the last 6 months have been doing this.
- deleted 7y ago[deleted]
- OptionX 7y agoLet python2 die people. Move on. Isn't 10 years of tech debt enough?
- hartator 7y agoI still don’t fully get why we can’t have ‘print x’ in Python 3. We would have avoided 10 years of schism for something that was soooo backward incompatible.
- maest 7y agoThere are ample discussions about the change in `print x` syntax in Python all over the web.
- hartator 7y agoWell everyone understands the academic reasons. (Print is a function and now you can do ‘my_print_function = print’) But really it was not necessary. What piece of code is taking advantage that print is a pure function nowadays? [EDIT] I am genuinely curious.
- int_19h 7y agoIt's the people who are learning the language from scratch taking advantage of this simplification, because they don't need to learn the special syntax of print with all its warts (like trailing comma).
- deleted 7y ago[deleted]
- tyingq 7y agoInteresting. Is there anything here to deal with the three states[1] of "bytes" and "barray" vs "strings"? That was the hardest part, for me, to release an extension that was 2vs3 agnostic. Personally, resorted to some ugly hacks with version detection, barray detection, etc to make a 2/3 compatible extension. [1] The three states being 2.x prior to recognizing bytes, 2.x sorta recognizing, and 3.x hard recognizing.
- habosa 7y agoIs there a simple guide to understanding the str/unicode changes from python 2 to 3? I've made mistakes with strings that ruined every single piece of code I've upgraded from 2 to 3 unless I just littered the code with defensive six() calls ... and even then some things still broke.
- stefantalpalaru 7y agoPython2 is dead. Long live Python2! https://github.com/naftaliharris/tauthon/pull/131 https://github.com/naftaliharris/tauthon/pull/131