6 ms·
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 st
by 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 agoActually 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 agoPython2 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 agojust plain for line in yourfile: print line with yourfile containing non-ascii characters and running it in windows console.
- colejohnson66 10y agoThat sounds like a limitation of the Windows console, not the programming language.
- comex 10y agoIt'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.
- rjurney 10y agoStop using the Windows console. Or fix it. More rational than a breaking upgrade to Python 3.
- paulddraper 10y agoFixing the Windows console rather than upgrading to Python 3 is the only sensible choice. </s>
- Animats 10y agoIt is, and Java has similar problems on Windows. The Windows console can be switched to Unicode, but by default, it emulates the IBM 5150 PC character set, circa 1980. It's not even ISO LATIN-1. Works fine on Linux.
- mark-r 10y agoYes, it will explode if you try to write a Unicode string to something that doesn't have UTF-8 encoding by default. But it won't explode if you write byte strings, or if your default encoding is UTF-8.
- vetinari 10y agoWindows console is that case which doesn't default to UTF-8. At the time when I was working with it, py2 defaulted to ascii. For some locales Windows has additional bonus, the Ansi (GUI) encoding is different than OEM (console) and it was heroic undertaking to make your program work correctly for both. Python3 works out of the box.
- mark-r 10y agoI can sympathize, Windows is my environment too. But I'm not blind to other environments where some simplifying assumptions can be made. For true insanity try adding IDLE to the mix. IDLE under Windows in Python 2 will let you output UTF-8, but won't accept it as input. Python 3 is more consistent.
- kstrauser 10y agoI had thought you were being sarcastic in your grandparent post.
- int_19h 10y agoPython2 supports Unicode, but it requires careful thought and deliberation to do it right - and at the same time makes it very easy to do it wrong (by assuming all bytes are strings etc). As a result, when such code is written by people with little awareness of the world beyond ASCII or Latin-1, it tends to be buggy with locales that need more than that. And yes, it's not really a Python issue, it's a more generic issue with treating bytearrays as strings (what you refer to as POSIX text model). Until UTF-8 became the standard encoding everywhere, there were many Linux apps that couldn't handle non-Latin1 encodings properly, either. It was also the case on Windows in 9x days, for all the same reasons.
- the_why_of_y 10y agoWindows doesn't actually support Unicode, not really (for backwards compatibility reasons): it's just UCS-2 at the OS level, and hence you can't represent OS level strings as UTF-8 without data loss, because in practice you need to handle lone UTF-16 surrogate code units. This is why WTF-8 exists. https://simonsapin.github.io/wtf-8/ https://simonsapin.github.io/wtf-8/