6 ms·

Except Python2 is the POSIX standard on how to handle this and I prefer retro OSs without a bytes/string distinction. Python3 is the Windows way of handling st

Except Python2 is the POSIX standard on how to handle this and I prefer retro OSs without a bytes/string distinction. Python3 is the Windows way of handling strings so the change was pure churn. Both are valid, but Linux is "pretty popular" right? So why break everyone's code just to churn the pot. If it was good for Kernigan and Richie, good for Joe Ossanna, good for Robert Pike well it's good enough for me.

klodolph 10y ago
There isn't a "Windows" way of handling strings. You can handle strings however you want, just make sure that you pass the right data to syscalls. Windows APIs take UTF-16 or some other code page. Linux takes bytes. OS X takes UTF-8. There is no greatest common denominator. But if you use Unicode, then at least there's a well-defined way to write the syscall wrappers on all platforms. And it's not like Python 3 is forcing you to give up bytes. You can still os.listdir(b'/some/dir') and you'll get a list of bytes objects back. It's just that that's not default, since using Unicode by default simply makes more sense on a cross-platform system.
jowiar 10y ago
The problem is it might be good enough for Kernighan and Ritchie, but it's not good enough for Chávez and Çelik (or, well, most of the world). The A in ASCII stands for "American" -- and it gives a good indication of where you can look to find a whole lot of folks who ASCII isn't good enough for.
- true_religion 10y ago
  Actually I'd have naively thought it meant America as in "The Americans" including South America. It's no wonder the IANA want's to change it into US-ASCII (or USA-SCII).
- BuckRogers 10y ago
  Python2 supports unicode. Chávez and Çelik are covered. I'll take Python2's POSIX text model over Microsoft's default unicode strings every time because I prefer Linux. At this point in time see no reason to cater to a shrinking server platform. Not to mention they didn't even get unicode right with Python3. Google did with Go (assume UTF8).
  - vetinari 10y ago
    > Python2 supports unicode. Chávez and Çelik are covered. Most python2 code doesn't. It has a nice property of exploding spectacularly when the string you are writing out to console or file contains Chávez or Çelik.
    - the_mitsuhiko 10y ago
      > Most python2 code doesn't. Citation needed. I can't say I ever had practical issues with not being able to handle unicode on Python if I needed. No matter which library. Please give practical examples of where you cannot deal with unicode on Python 2.
      - vetinari 10y ago
        just plain for line in yourfile: print line with yourfile containing non-ascii characters and running it in windows console.
        colejohnson66 10y ago
        That sounds like a limitation of the Windows console, not the programming language.
        comex 10y ago
        It's a limitation of how the programming language interacts with the Windows console, and it's a mistake. If you are writing potentially-garbled strings directly to the console, there is already no guarantee that the output will properly reflect the string or e.g. copying and pasting will work correctly, because the string could include backspace characters, or a ton of newlines. Therefore it doesn't make sense to do anything other than make a 'best effort' attempt when rendering strings to the console, including with Unicode handling. If it works, great, but if the string is invalid Unicode, that's only one of multiple problematic cases, so what exactly is throwing an exception supposed to accomplish? Python should use replacement characters by default in this case.
toyg 10y ago
> So why break everyone's code Dunno about you, but the amount of encoding/decoding errors in Py2 broke my little code multiple times in the past. "oh yeah I'll just fetch this html page"... all good, until that page contains non-ASCII and then BOOM. With Py3 you're forced to think about this sort of issues right away and with minimal fuss you're sorted for life.
- deleted 10y ago
  [deleted]

klodolph 10y ago

There isn't a "Windows" way of handling strings. You can handle strings however you want, just make sure that you pass the right data to syscalls. Windows APIs take UTF-16 or some other code page. Linux takes bytes. OS X takes UTF-8. There is no greatest common denominator. But if you use Unicode, then at least there's a well-defined way to write the syscall wrappers on all platforms. And it's not like Python 3 is forcing you to give up bytes. You can still os.listdir(b'/some/dir') and you'll get a list of bytes objects back. It's just that that's not default, since using Unicode by default simply makes more sense on a cross-platform system.

jowiar 10y ago

The problem is it might be good enough for Kernighan and Ritchie, but it's not good enough for Chávez and Çelik (or, well, most of the world). The A in ASCII stands for "American" -- and it gives a good indication of where you can look to find a whole lot of folks who ASCII isn't good enough for.

true_religion 10y ago
Actually I'd have naively thought it meant America as in "The Americans" including South America. It's no wonder the IANA want's to change it into US-ASCII (or USA-SCII).
BuckRogers 10y ago
Python2 supports unicode. Chávez and Çelik are covered. I'll take Python2's POSIX text model over Microsoft's default unicode strings every time because I prefer Linux. At this point in time see no reason to cater to a shrinking server platform. Not to mention they didn't even get unicode right with Python3. Google did with Go (assume UTF8).
- vetinari 10y ago
  > Python2 supports unicode. Chávez and Çelik are covered. Most python2 code doesn't. It has a nice property of exploding spectacularly when the string you are writing out to console or file contains Chávez or Çelik.
  - the_mitsuhiko 10y ago
    > Most python2 code doesn't. Citation needed. I can't say I ever had practical issues with not being able to handle unicode on Python if I needed. No matter which library. Please give practical examples of where you cannot deal with unicode on Python 2.
    - vetinari 10y ago
      just plain for line in yourfile: print line with yourfile containing non-ascii characters and running it in windows console.
      - colejohnson66 10y ago
        That sounds like a limitation of the Windows console, not the programming language.
        comex 10y ago
        It's a limitation of how the programming language interacts with the Windows console, and it's a mistake. If you are writing potentially-garbled strings directly to the console, there is already no guarantee that the output will properly reflect the string or e.g. copying and pasting will work correctly, because the string could include backspace characters, or a ton of newlines. Therefore it doesn't make sense to do anything other than make a 'best effort' attempt when rendering strings to the console, including with Unicode handling. If it works, great, but if the string is invalid Unicode, that's only one of multiple problematic cases, so what exactly is throwing an exception supposed to accomplish? Python should use replacement characters by default in this case.

toyg 10y ago

> So why break everyone's code Dunno about you, but the amount of encoding/decoding errors in Py2 broke my little code multiple times in the past. "oh yeah I'll just fetch this html page"... all good, until that page contains non-ASCII and then BOOM. With Py3 you're forced to think about this sort of issues right away and with minimal fuss you're sorted for life.

deleted 10y ago
[deleted]