4 ms·

I fully agree. Python 3 makes life much, much easier with non-ASCII languages and prevents the annoying Unicode conversion bugs you see in most Python 2 code ba

by eeZi 11y ago

I fully agree. Python 3 makes life much, much easier with non-ASCII languages and prevents the annoying Unicode conversion bugs you see in most Python 2 code bases. It's also very intuitive, which is great for teaching - I've always had a hard time explaining the difference between "strings" and "unicode" objects in Python 2, but the clear boundary makes it straight-forward in Python 3.

SeanDav 11y ago
Not always straight forward in Python 3. Try explaining to your class how to ignore case in string comparisons.
- zo1 11y ago
  That depends on the type of strings you are comparing. If you include the full Unicode set, you're going to run in to huge troubles in probably all languages simply due to the nature of the Unicode character set, rather than the specific language's handling of strings and Unicode code points. But, personally, if you're teaching Python to a class, whether it's 2.x or 3.x. You should probably stick to using some variation of string.upper() == string.upper() to explain simple comparisons, due to simplicity.
- squeaky-clean 11y ago
  >Try explaining to your class how to ignore case in string comparisons Okay: You can't. You'll need to convert both strings to the same case, and then compare those. In the majority of cases, you can do: return string_a.lower() == string_b.lower() But sometimes that won't work, because converting case isn't always easy. And that's a unicode issue, not a python issue. It's not even completely a unicode issue, just a "writing can be very weird" issue. For example, "ß" (U+00DF) is a character that doesn't/shouldn't have an uppercase form. Unicode does support it as U+1E9E, but all the examples I know of will convert it to "SS" ([U+0053, U+0053]) instead. Try this in a javascript console, for example. > "ß".toUpperCase().toLowerCase() === "ß".toLowerCase() false > "ß".toUpperCase() === "SS".toUpperCase() true > "ß".toLowerCase() === "SS".toLowerCase() false > "ß".length 1 > "ß".toLowerCase().length 1 > "ß".toUpperCase().length 2 > "ß".toUpperCase().toLowerCase() "ss" Also, try ctrl+f'ing for "ss" on the Wiki page for ß [0] and see what it matches. Or ctrl+f this page for "ß" and it will match every "ss". I think it's pretty neat. [0] https://en.wikipedia.org/wiki/%C3%9F https://en.wikipedia.org/wiki/%C3%9F (edit: You might already know everything in this comment, but I started writing and it ended up being a cool exercise for myself, so I figured I'd submit).
  - throw_away 11y ago
    Interesting that the "ss" search only works on safari and chrome, but not on firefox (which happens to be the only browser that lets you easily toggle case-matching AFAICT). I presume this means that the first two went with a toUpperCase() approach while FF went with toLowerCase(). I wonder which choice is better in the face of unicode type oddities like this one.
  - mangecoeur 11y ago
    > "writing can be very weird" Absolutely! I think there's a lot of baggage in computing because it happened to emerge in places where language could mostly be written in simple characters with surprisingly simple rules. When exported internationally suddenly you deal with "oddities" that are really rather the norm in other languages. In French for example is customary NOT to put accents on capital letters, even though it's possible. But then again sometime people do it anyway - it's not a hard rule. So often converting to lowercase may require contextual understanding because some words are written the same but with different accents, and would capitalize to the same string. Which word was meant would only be evident from the context of the sentence. I suspect that if computing had rather developed somewhere where these things were commonplace we would have much better handling of it today.
- c-oreills 11y ago
  This is exactly what str.casefold is for: https://docs.python.org/3/library/stdtypes.html#str.casefold https://docs.python.org/3/library/stdtypes.html#str.casefold
  - SeanDav 11y ago
    casefold is only part of the story and by itself does not supply a complete solution.
    - c-oreills 11y ago
      Could you expand on where it falls short? I'm interested, having not yet relied on it heavily.
takeda 11y ago
This is also significant reason why people have problem when migrating py2 code to py3. The code is actually buggy and mixes strings with bytes. Once they run it in Py3 all of the bugs show up because Py3 is stricter about it. For the same reason if you need to write code that should work on Py2 and Py3, it's much easier to write it on Py3 and then add backward compatibility through "from __future__ import ..." and the six module.
- eeZi 11y ago
  I've heard lots of good things about this project, by the way: http://python-future.org/ http://python-future.org/ It's much less clunky than six. Instead of manually adding the compatibility layers to your code, it automates the process, which results in cleaner code. It can even translate (some) Python 2 modules on-the-fly. Many projects switched to it from six.

by eeZi 11y ago

SeanDav 11y ago

Not always straight forward in Python 3. Try explaining to your class how to ignore case in string comparisons.

zo1 11y ago
That depends on the type of strings you are comparing. If you include the full Unicode set, you're going to run in to huge troubles in probably all languages simply due to the nature of the Unicode character set, rather than the specific language's handling of strings and Unicode code points. But, personally, if you're teaching Python to a class, whether it's 2.x or 3.x. You should probably stick to using some variation of string.upper() == string.upper() to explain simple comparisons, due to simplicity.
squeaky-clean 11y ago
>Try explaining to your class how to ignore case in string comparisons Okay: You can't. You'll need to convert both strings to the same case, and then compare those. In the majority of cases, you can do: return string_a.lower() == string_b.lower() But sometimes that won't work, because converting case isn't always easy. And that's a unicode issue, not a python issue. It's not even completely a unicode issue, just a "writing can be very weird" issue. For example, "ß" (U+00DF) is a character that doesn't/shouldn't have an uppercase form. Unicode does support it as U+1E9E, but all the examples I know of will convert it to "SS" ([U+0053, U+0053]) instead. Try this in a javascript console, for example. > "ß".toUpperCase().toLowerCase() === "ß".toLowerCase() false > "ß".toUpperCase() === "SS".toUpperCase() true > "ß".toLowerCase() === "SS".toLowerCase() false > "ß".length 1 > "ß".toLowerCase().length 1 > "ß".toUpperCase().length 2 > "ß".toUpperCase().toLowerCase() "ss" Also, try ctrl+f'ing for "ss" on the Wiki page for ß [0] and see what it matches. Or ctrl+f this page for "ß" and it will match every "ss". I think it's pretty neat. [0] https://en.wikipedia.org/wiki/%C3%9F https://en.wikipedia.org/wiki/%C3%9F (edit: You might already know everything in this comment, but I started writing and it ended up being a cool exercise for myself, so I figured I'd submit).
- throw_away 11y ago
  Interesting that the "ss" search only works on safari and chrome, but not on firefox (which happens to be the only browser that lets you easily toggle case-matching AFAICT). I presume this means that the first two went with a toUpperCase() approach while FF went with toLowerCase(). I wonder which choice is better in the face of unicode type oddities like this one.
- mangecoeur 11y ago
  > "writing can be very weird" Absolutely! I think there's a lot of baggage in computing because it happened to emerge in places where language could mostly be written in simple characters with surprisingly simple rules. When exported internationally suddenly you deal with "oddities" that are really rather the norm in other languages. In French for example is customary NOT to put accents on capital letters, even though it's possible. But then again sometime people do it anyway - it's not a hard rule. So often converting to lowercase may require contextual understanding because some words are written the same but with different accents, and would capitalize to the same string. Which word was meant would only be evident from the context of the sentence. I suspect that if computing had rather developed somewhere where these things were commonplace we would have much better handling of it today.
c-oreills 11y ago
This is exactly what str.casefold is for: https://docs.python.org/3/library/stdtypes.html#str.casefold https://docs.python.org/3/library/stdtypes.html#str.casefold
- SeanDav 11y ago
  casefold is only part of the story and by itself does not supply a complete solution.
  - c-oreills 11y ago
    Could you expand on where it falls short? I'm interested, having not yet relied on it heavily.

takeda 11y ago

This is also significant reason why people have problem when migrating py2 code to py3. The code is actually buggy and mixes strings with bytes. Once they run it in Py3 all of the bugs show up because Py3 is stricter about it. For the same reason if you need to write code that should work on Py2 and Py3, it's much easier to write it on Py3 and then add backward compatibility through "from __future__ import ..." and the six module.

eeZi 11y ago
I've heard lots of good things about this project, by the way: http://python-future.org/ http://python-future.org/ It's much less clunky than six. Instead of manually adding the compatibility layers to your code, it automates the process, which results in cleaner code. It can even translate (some) Python 2 modules on-the-fly. Many projects switched to it from six.