8 ms·

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.

praulv 9y ago
Yes, one of the most painful aspects of Python 2 to 3 migration.
- Bedon292 9y ago
  I found the opposite. When having to deal with utf-8 text, I hated life in 2, but 3 handles it with ease. It made life so much better.
- rcthompson 9y ago
  Of course string encoding is the most painful aspect of migrating from Python 2 to 3. The backwards-incompatible fix to how Python handles string encoding is literally the reason Python 3 exists.
nas 9y ago
I don't think anyone is going to pry it from you. If you want to keep using 2.7, go ahead. It's open source so you can even hire someone to keep maintaining it for you. 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".
hetman 9y ago
It replaces one set of quirky hacks for a different set, just in different parts of your code. So in a way it's no worse. 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.
- Something1234 9y ago
  Whats the difference between the approaches?
  - int_19h 9y ago
    In Python 3, all strings are Unicode, period. When you need a sequence of bytes that's something else, there's a separate types for that (called, unsurprisingly, "bytes"). If you need to treat it as a string, you use the decode() method and pass the encoding should be used to interpret it. If you need to get byes out of a string, it's the reverse process - you call encode(), and, again, specify the encoding. 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.
- hyperbovine 9y ago
  I wonder if this has anything to do with Matz being Japanese. I do my best to avoid Unicode at all costs because as a native English speaker ASCII was working out great for me.
  - derefr 9y ago
    Even if you're only shipping to an English-speaking US audience, people are still going to be throwing Unicode at your app. One word: emojis.
    - alphaalpha101 9y ago
      Emojis are utterly stupid and should never have been added to Unicode. They are not human language, at all.
  - makapuf 9y ago
derefr 9y ago
You know the phrase, "you don't have to go home, but you can't stay here"? 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.
- xapata 9y ago
  Nah, I'm sure you will be able to get commercial support for at least another decade.
- nas 9y ago
  I think the amount of Python 2 source code existing in the world is too large for Python 2.7.x to stop working. A lot of that code is just never going to get ported to Python 3. Companies don't have the budget to do it. So, somehow there will still be a Python 2 interpreter to run the code, even after 2020. 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.
  - derefr 9y ago
    > I think the amount of Python 2 source code existing in the world is too large for Python 2.7.x to stop working. A lot of that code is just never going to get ported to Python 3. Companies don't have the budget to do it. So, somehow there will still be a Python 2 interpreter to run the code, even after 2020. 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.
  - acqq 9y ago
rcthompson 9y ago
I'm open to the argument that Python 3's handling of string encoding is not ideal. But after using Python 3, I'm not willing to go back to a language that allows the programmer to freely mix encoded and decoded strings and uses the same type to represent both. That way lies insanity, and I'm glad to be rid of it. 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.
ggm 9y ago
I too felt 7 bit ascii was a good thing, and I believe I know members of the original ANSI committee who worked on it. 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.

praulv 9y ago

Yes, one of the most painful aspects of Python 2 to 3 migration.

Bedon292 9y ago
I found the opposite. When having to deal with utf-8 text, I hated life in 2, but 3 handles it with ease. It made life so much better.
rcthompson 9y ago
Of course string encoding is the most painful aspect of migrating from Python 2 to 3. The backwards-incompatible fix to how Python handles string encoding is literally the reason Python 3 exists.

nas 9y ago

I don't think anyone is going to pry it from you. If you want to keep using 2.7, go ahead. It's open source so you can even hire someone to keep maintaining it for you. 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".

hetman 9y ago

It replaces one set of quirky hacks for a different set, just in different parts of your code. So in a way it's no worse. 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.

Something1234 9y ago
Whats the difference between the approaches?
- int_19h 9y ago
  In Python 3, all strings are Unicode, period. When you need a sequence of bytes that's something else, there's a separate types for that (called, unsurprisingly, "bytes"). If you need to treat it as a string, you use the decode() method and pass the encoding should be used to interpret it. If you need to get byes out of a string, it's the reverse process - you call encode(), and, again, specify the encoding. 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.
hyperbovine 9y ago
I wonder if this has anything to do with Matz being Japanese. I do my best to avoid Unicode at all costs because as a native English speaker ASCII was working out great for me.
- derefr 9y ago
  Even if you're only shipping to an English-speaking US audience, people are still going to be throwing Unicode at your app. One word: emojis.
  - alphaalpha101 9y ago
    Emojis are utterly stupid and should never have been added to Unicode. They are not human language, at all.
- makapuf 9y ago

derefr 9y ago

You know the phrase, "you don't have to go home, but you can't stay here"? 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.

xapata 9y ago
Nah, I'm sure you will be able to get commercial support for at least another decade.
nas 9y ago
I think the amount of Python 2 source code existing in the world is too large for Python 2.7.x to stop working. A lot of that code is just never going to get ported to Python 3. Companies don't have the budget to do it. So, somehow there will still be a Python 2 interpreter to run the code, even after 2020. 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.
- derefr 9y ago
  > I think the amount of Python 2 source code existing in the world is too large for Python 2.7.x to stop working. A lot of that code is just never going to get ported to Python 3. Companies don't have the budget to do it. So, somehow there will still be a Python 2 interpreter to run the code, even after 2020. 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.
- acqq 9y ago

rcthompson 9y ago

I'm open to the argument that Python 3's handling of string encoding is not ideal. But after using Python 3, I'm not willing to go back to a language that allows the programmer to freely mix encoded and decoded strings and uses the same type to represent both. That way lies insanity, and I'm glad to be rid of it. 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.

ggm 9y ago

I too felt 7 bit ascii was a good thing, and I believe I know members of the original ANSI committee who worked on it. 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.