You need one of these.
https://golang.org/cmd/fix/
Why I'm Making Python 2.8
71–80 of 392 posts
Re: Why I'm Making Python 2.8
#72I can't fault a single thing in his justification. This should have been the approach to modernising python all along.
This approach could not have worked for modernizing python. The whole point of the Python 3 thing was to be able to remove warts in the language that could not have been fixed without breaking backwards compatibility. One core part of this is unicode support -- Python had a horrible story for international text before this. The fact that there are some parts of "modern" Python which could have been implemented in Pyt…
Python 3 fixes no fundamental issues with python 2 and introduced far more warts than it removed. GIL is still there, crummy runtime is still there and unicode is now an even greater mess. I really wonder how many people who bang on about unicode actually have a good grasp of unicode and text processing because python3's unicode design is obviously terrible. I can now access or count code points in O(1) (neither of which is in any way useful) at the cost of tremendously increasing space and time overhead for any basic text operation on non ascii text and having some bizarre hacks to deal with the fact that pretending that stdin and stdout and sys.argv are always text.
Re: Why I'm Making Python 2.8
#73I can't fault a single thing in his justification. This should have been the approach to modernising python all along.
This approach could not have worked for modernizing python. The whole point of the Python 3 thing was to be able to remove warts in the language that could not have been fixed without breaking backwards compatibility. One core part of this is unicode support -- Python had a horrible story for international text before this. The fact that there are some parts of "modern" Python which could have been implemented in Pyt…
Python had a horrible story for international text before this.
No, Python had a horrible story for text, and people who worked in limited/sheltered domains didn't realize it. I personally lost all kinds of valuable hours of my life fighting with Python 2's "pretend everything is ASCII until it isn't, then fall over dead" model, because I -- a US citizen, working at US companies, and for quite a while dealing only with English-language content -- still ran into non-ASCII characters with regularity.
And here I'm being charitable; I simply refuse to believe that the overwhelming majority of people who used Python 2 never once had to deal with someone copy/pasting text out of Word or another program that used "smart quotes".
Re: Why I'm Making Python 2.8
#74Earlier quoted context omitted.
Python 2.7 is outdated by Python 3.5. The fact that there is a bugfix release doesn't change that. I mean look at other things. You can still program in C 89 or FORTRAN 77 or COBOL 74 (and no doubt there is somebody still supporting compilers and runtimes for those), but they are all obsolete standards. Addendum: I think for standards like programming language semantics (which in case of Python is directly embodied i…
> Addendum: I think for standards like programming language semantics (which in case of Python is directly embodied in the C implementation), "obsolete" means there is a new standard by some official body (say, the developer of the old standard) that addresses shortcomings of the old standard. Really? So even if no one ever uses it, it still renders the old one obsolete?!
> So even if no one ever uses it, it still renders the old one obsolete?!
This is a strawman, because I don't think this ever happens (feel free to give an example). There will always be people who try to use new standard; they may abandon it later, but they will at least try to use it.
In any case, this is not really relevant to Python 3, which is used plenty and more and more every day.
And your insistence that Python 2.7 is not dead really reminds me of this sketch: https://www.youtube.com/watch?v=npjOSLCR2hE
Re: Why I'm Making Python 2.8
#75Earlier quoted context omitted.
I'd argue Python 2.7 counts as no longer produced. The 2.7.x releases with their bugfixes are akin to an electronics company still honoring the warranty of tape recorders and still repairing them. That doesn't mean tape recorders are not obsolete, especially since the company is not making them anymore. I consider the parallel 'making software' to be the process of feature proposal -> patch -> review -> merge
In your eyes is anything that isn't getting more and more features added every few months necessarily obsolete? Can't something just become mature and fulfill its goals at some point? Do you consider T-shirts to be obsolete too? If they kept adding more and more attachments ("features") to your clothes every few months to prevent them from becoming "obsolete" you'd be walking around in really heavy clothing...
Your comment is particularly apt as the programming language du jour is driven by fashion, not technology. We could still be using COBOL and be just as productive churning our CRUD apps as we are with the latest JS frameworks today... But one's hot and one's not.
Re: Why I'm Making Python 2.8
#76this is incredible - give me unicode support in python 2. asyncio ? probably .. i'll still be happy with gevent. This is a clear path for a python upgrade.
give me unicode support in python 2
If by this you mean "give me exactly Python 3's text model without breaking my unmodified Python 2 code", you should be aware that A) this is impossible because B) the Python 3 text model is backwards-incompatible with unmodified Python 2 code, and C) that's kinda why Python 3 existed and was backwards-incompatible.
Re: Why I'm Making Python 2.8
#77Just call it Unofficial Python 2.8 instead of Python 2.8
Re: Why I'm Making Python 2.8
#78Earlier quoted context omitted.
In your eyes is anything that isn't getting more and more features added every few months necessarily obsolete? Can't something just become mature and fulfill its goals at some point? Do you consider T-shirts to be obsolete too? If they kept adding more and more attachments ("features") to your clothes every few months to prevent them from becoming "obsolete" you'd be walking around in really heavy clothing...
Tape recorders are not still being made; verdict: obsolete T-shirts are still being made; verdict: not obsolete Python 2 is not still being made; verdict: obsolete
This is just wrong. For example, the "best" recording microphone (to many artists), the U67, can no longer be made because the parts aren't available anymore. Yet it is the most popular mic, and 100% not obsolete.
Similarly, Python 2 might not be made anymore, but it is used everywhere, and people are making new things with it. So...it's also not obsolete.
Re: Why I'm Making Python 2.8
#79Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. Python 3 I think people and businesses with python 2 code would be better off moving their code bases to python 3 instead of doing things like this.
What about not spending time and money and just keep using python 2 for software that already uses it. And only use python 3 for new code bases.
This is how you end up still running fixed-format Fortran code in 2016.
If your software is being actively maintained, it's time to move to Python 3.
Re: Why I'm Making Python 2.8
#80As others have said, maybe this project fixes some actual problems and backports some features from 3, but this isn't "Python". Beyond the fact that Python is a trademark of the Python Software Foundation, Python is more than the language, it's the community and the tools (as with every programming language). So while there are some vocal people that really dislike Python 3 (either in part or wholly), my understanding is that with the planned phase out of Python 2 and Python 2 only receiving bug fixes at this point, much of the industry is transitioning to Python 3 (either currently doing so or planning to) and so it seems relatively fruitless to attempt to build upon Python 2. I personally think the effort put into this would be much better spent making tooling around Python 2 to 3 transformations.
I also think it's pretty irresponsible of the author to call this Python 2.8, because it may cause confusion to developers unfamiliar with the history and come from a tutorial that is still in Python 2 (it does show up on the first page of Google for me). It's also especially irresponsible and hubristic to attempt to make a language that is seemingly compatible with both Python 2 and 3, because 1) I trust that if it was possible Guido and the other developers would have made it, and 2) it can cause significant confusion when code doesn't work when it hits an edge case, and then the whole tooling around it can't be guaranteed to work. The last thing I'd want in my programming language is unaccounted for ambiguity.