I've said it before, I'll say it again. I don't care for everything-is-unicode-by-default.
You can take my Python 2 when you pry it from my cold dead hands.
You can take my Python 2 when you pry it from my cold dead hands.
However, be aware that the vast majority of the people maintaining Python have moved on to 3.x. 2.7.x continues to be maintained because the team believes in giving people a stable platform and a long maintenance window. Long does not mean forever though and most of the people back-porting fixes to 2.7.x will stop by 2020.
So, you should have a plan for that. May give 3.x a spin and see how it works for you. I feel like 3.x adoption is speeding up because people have tried porting their code and decided that "yes, 3.x is better".
In Python 2, I could never seem to figure out how to do string encoding properly. After trying to reason about the code and put the calls to str.encode() and str.decode() in what I thought was the right place and inevitably failing, my only recourse was to sprinkle random calls to str.encode() and str.decode() throughout my code like magic pixie dust until errors stopped happening. In Python 3, if I do it wrong, I get an easy-to-debug TypeError. For bonus points, if I use Mypy, I can get that error without even having to run the code.
But, I now live and work in the Asia-Pacific region, and I regularly interact with data and content which is not represented in 7 bit ascii. This has altered my perspective.
My comrades from 7 bit land also migrated into a world of homophones. It is entirely true you can get into some awful places regarding what things look like and what semantically they mean, but the one thing that has never come up, is what errors of handling it introduced into the code: the code, is doing what it does. It is how you interpret it, that has to change.
uStrings just work. Unclench your Undead fists, and accept the news from your brothers and sisters outside of paper tape.
You don't have to move to Python 3, but Python 2 is gonna be EOLed. If you don't agree with Python 3's stances on things, it might be time to find another language entirely.
That said, when nearly all of the Python 3rd-party library developers are targeting Python 3, do you really want to be stuck on 2.x? I think that's going to be the ultimate death of new Python 2.x development. The NumPy example seems typical. I.e. the cost of supporting 2.x is very soon not going to be worth it.
It seems clear to me now that there is not going to be a large faction of 3rd party library developers who refuse to move from 2.x. That is unlike Perl 5. As a Python developer, this is very happy result. The 2 to 3 transition was extremely painful but it appears to be mostly behind us now. Having two separate "flavours" of Python (2.x and 3.x) would have been bad.
Sure, but—as other people mention down-thread—there are still COBOL programs, and even COBOL (maintenance) developers. There's just no community for active, new COBOL development. That's what it means for a language to be EOLed.
Exactly. And that is the major fuup that Python 3 brought. There was no fundamental reason to make most of the Python 2 code incompatible with the "better" and "newer" version. The really good Python 3 would have accepted most of the Python 2 code and execute it, while allowing the new 3 "goodies."
Only a year ago, I've installed "just" Python 3 on my main computer -- "Python 3 is mature enough" I've thought. Then I wanted to solve some problem X. Found the code that does 90% on the web. Try to run -- doesn't work on Python 3. Adjusting it. It runs after my changes, but I've lost time for something unnecessary. Then I've tried to solve some problem Y. The story repeats. The third time, I've just decided that it's not worth. I've installed 2 again and I can't be happier.
And all that was for my non-Numpy related work. There were some years where the libraries using Numpy were only Python 2, even after Numpy got its own 3 version.
So Python 3 was so very wrong for too long. The worst upgrade path I've lived through. And completely unnecessary. It was absolutely technically possible to make it much much easier to move.
I'd be happy if I'm wrong though...
In my experience, for my purposes and use cases, obviously not, exactly as I wrote above. And it didn't have to be that way for most of the code, I claim that, knowing how little additional code were needed to have a different result: compare with the Linux Kernel, much more complex piece of code, where "kernel never breaks user code" because Linus set that goal. Python is much, much less complex than Linux Kernel, and the same goal was possible: not breaking at least most of code written for 2, while still allowing different new code. The overhead would be insignificant. Note that even without that overhead, Python 3 was (maybe still is) significantly slower than 2. So there is really no valid excuse.
But to me ASCII seems like a hindrance.
``` fmt.Println("Hello, 世界") ```
This line of go lang looks beautiful. I bet they never have to worry about bytes vs Unicode.
Here is python...
https://www.youtube.com/watch?v=sgHbC6udIqc
I'll add one more assertion to the list. People are born and people die. It is not fair for us to impose our mistakes and sins to the next generation. With that being said, my thought was simply all the scripts that are in python (even the simple build for Firefox was python 2 only last time I checked).
The way forward for anyone new to python is for us to tell them: Python 2 doesn't matter. Don't look at it. Learn python by which I mean 3.0+
I still don't get why Google of all places can't support python 3 in its standard app engine. To me it sounds like standard is deprecated for the flexible (which doesn't have a free tier).
I have to say I was sceptical of Ruby 1.9's new approach to Unicode thinking Python 3.0's approach looked much cleaner. It does on paper. In practice though, I have to admit I get where Ruby was going with it all now.
In Ruby, strings are byte sequences with encoding attached. Unicode is not special - it's just one of many available encodings. And different strings in the program can have different encodings. This makes it possible to represent data richer than what Unicode allows (e.g. the various East Asian encodings that avoid CJK unification issues). But it also means that it might be impossible to e.g. concatenate two random strings, or even compare them for equality in a meaningful way, because their encodings are incompatible.