4 ms·

I didn't read the article as saying "I hate the complexity of Unicode", I read it as a complaint about language/library ergonomics. Comparing a string to a byte

• acdha 8y ago
  It read to me as not learning how things worked and then blaming the language when an upgrade revealed that misunderstanding rather than taking the time to learn how things actually work.
  • slavik81 8y ago
    Even Python 3 makes it easy to ignore how things work. open happily accepts a string. Regex works on bytes. open and the standard streams can be used for reading and writing without explicitly specifying any encoding or error handling strategy. There's a default value for encoding on codec.encode and codec.decode. And nothing is checked statically, so you get to discover all your mistakes at runtime—and often only with a specific combination of inputs and environment. People don't think about these things because Python encourages you to ignore them. Until it doesn't. There'd be a lot less confusion if Python 3 were more strict/explicit about conversions.
• erdewit 8y ago
  > Comparing a string to a bytestring should not just always evaluate to false, it should (IMHO) raise a type error. Equality testing is implicitly done in a lot of places (like searching), it would become a bit of a hassle if the basic types were to throw exceptions when compared with each other.
  • sly010 8y ago
    It would also result in correct code sooner.
    • paulddraper 8y ago
      Perhaps, but the ship sailed long ago on that one >>> 1 == '1' False
  • josteink 8y ago
    Finding bugs early is considered a hastle these days? Really?
    • adjkant 8y ago
      Not saying it's right but: For something like Unicode, I think the point is that it "just worked" before where it would have been a lot more time and effort to get it "working" in say Java. Types and compile/runtime errors are a balance in the end that depends on the use case and if the programmer wants something that works (for the short term usually) or is resilient and will work long term. IMO, the influx in popularity of untyped languages (Javascript being used on the server side, ew) is a sign that so much coding today is not done for the long haul. I think there are good balances to be hit though, and Unicode is a place that highlights that python could use some better optional typing aid, as Typescript brought to JS.
      • josteink 8y ago
        As someone with so called “Unicode-characters” in my name, I have encountered bugs and issues on every single American website in the history of the internets, and you will have to forgive me for preferring correctness over programmer convenience. For me it’s literally personal.
        • im3w1l 8y ago
          How many more ads are you willing to watch to pay for the correctness?
          • josteink 8y ago
            While your comment is trollish, I’ll let you know I’ve had many issues with payments because shitty web-sites have been unable to 1. Validate my name and 2. Correlate whatever their whitelist permits with actual information returned from the payment processor. So your inability to handle basic stuff like this is actually costing you money.
• wool_gather 8y ago
  Why would this be a type error? "Are these two things equivalent?" has an unambiguous answer regardless of whether the things are of different types. When they are not the same kind of thing, the answer is simply `False`. There's no reason to have a third answer "You're not allowed to ask that" for that case.
  • minitech 8y ago
    It would be a type error because that would be helpful. Since comparing a bytes to a str is not usually what you want, Python could make you be explicit about it. It’s too late now, and it might have been considered another backwards compatibility break (so a good thing to keep out of Python 3), but it’s not a bad idea on its own. Heterogeneous collections are pretty rare. Also, `==` doesn’t always answer the question of whether two things are equivalent in Python: >>> 1.0 == 1 True >>> {'a': 5} == OrderedDict({'a': 5}) True (OrderedDict equality isn’t transitive.)
    • gvx 8y ago
      Pretty rare but not unheard of. I do know that most of the code bases I work in would require significant reworking if I have to expect `==` to throw a TypeError for basic builtin types.
      • guitarbill 8y ago
        Not quite with ==, but there is precedence where operators with basic builtin types throw a TypeError when the operation doesn't make sense: >>> 0 > None Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: '>' not supported between instances of 'int' and 'NoneType'
        • wool_gather 8y ago
          Absolutely; there's no good boolean answer for > when you have different types, so the `TypeError` is perfect there.