2 ms·

Part of the issue is to do with bytes and strings being considered totally different by python but confusingly similar to people. The error from "file" != b"fi

Part of the issue is to do with bytes and strings being considered totally different by python but confusingly similar to people. The error from "file" != b"file" is particularly bad. It makes sense if you realise that a == b means a,b have the same type and their values are equal. But there is no way a even a reasonably careful programmer could spot this without super careful testing (and who’s to say they would remember to test b"file" and not "file"). Other ways this could be solved are: 1. String == bytes is true iff converting the string to bytes gives equality (but then can == become non transitive) 2. String == bytes raises (and so does string == string if encodings are different) 3. Type-specific equality operators like in lisp. But these are ugly and verbose which would discourage their use and so one would not think to use bytesEqual instead of == 4. A stricter/looser notion of equality that behaves as one of the above called eg === but this is also not great

xapata 8y ago
> The error from "file" != b"file" is particularly bad. It makes sense if you realise that a == b means a,b have the same type and their values are equal. But there is no way a even a reasonably careful programmer could spot this without super careful testing (and who’s to say they would remember to test b"file" and not "file"). I'm of the opposite opinion. I appreciate that b'a' != 'a'.
- dan-robertson 8y ago
  I don’t think it’s a problem that they aren’t equal. This is reasonable. The problem is that it is hard for one to foresee this error. The mental model of bytes and strings is likely to be either their equal-looking literals or a mental concept of “bytes and strings are basically the same except for some exceptions.” One cannot reasonably trace every variable to figure out whether it is a bytes or a string. The comparison a == b being false comparing strings to bytes makes sense when a and b could be anything. However when b is already definitely a (byte) string, it is more useful to get an error when a has a different type. What is your opinion on numbers: Should 1 == 1.0? What about 1+0j? Or 1/1 (the rational number, although I’m not sure this can be constructed)?
  - xapata 8y ago
    int and float being comparable is practical, though occasionally troublesome. Complex usually doesn't compare well across types. You can use a Fraction type for 1/1. I haven't formed an opinion about that, since I don't use them often.
ubernostrum 8y ago
It makes sense if you realise that a == b means a,b have the same type and their values are equal. Which is wrong. In Python, "a == b" is: True if a.__eq__(b) is True (short-circuiting the entire expression to True), or if a.__eq__(b) is NotImplemented and b.__eq__(a) is True. False if a.__eq__(b) is False (short-circuiting the entire expression to False), or if a.__eq__(b) is NotImplemented and b.__eq__(a) is True. TypeError if a.__eq__(b) is NotImplemented and b.__eq__(a) is NotImplemented.
- ubernostrum 8y ago
  Second line should read as below, can't edit: False if a.__eq__(b) is False (short-circuiting the entire expression to False), or if a.__eq__(b) is NotImplemented and b.__eq__(a) is False.

xapata 8y ago

> The error from "file" != b"file" is particularly bad. It makes sense if you realise that a == b means a,b have the same type and their values are equal. But there is no way a even a reasonably careful programmer could spot this without super careful testing (and who’s to say they would remember to test b"file" and not "file"). I'm of the opposite opinion. I appreciate that b'a' != 'a'.

dan-robertson 8y ago
I don’t think it’s a problem that they aren’t equal. This is reasonable. The problem is that it is hard for one to foresee this error. The mental model of bytes and strings is likely to be either their equal-looking literals or a mental concept of “bytes and strings are basically the same except for some exceptions.” One cannot reasonably trace every variable to figure out whether it is a bytes or a string. The comparison a == b being false comparing strings to bytes makes sense when a and b could be anything. However when b is already definitely a (byte) string, it is more useful to get an error when a has a different type. What is your opinion on numbers: Should 1 == 1.0? What about 1+0j? Or 1/1 (the rational number, although I’m not sure this can be constructed)?
- xapata 8y ago
  int and float being comparable is practical, though occasionally troublesome. Complex usually doesn't compare well across types. You can use a Fraction type for 1/1. I haven't formed an opinion about that, since I don't use them often.

ubernostrum 8y ago

It makes sense if you realise that a == b means a,b have the same type and their values are equal. Which is wrong. In Python, "a == b" is: True if a.__eq__(b) is True (short-circuiting the entire expression to True), or if a.__eq__(b) is NotImplemented and b.__eq__(a) is True. False if a.__eq__(b) is False (short-circuiting the entire expression to False), or if a.__eq__(b) is NotImplemented and b.__eq__(a) is True. TypeError if a.__eq__(b) is NotImplemented and b.__eq__(a) is NotImplemented.

ubernostrum 8y ago
Second line should read as below, can't edit: False if a.__eq__(b) is False (short-circuiting the entire expression to False), or if a.__eq__(b) is NotImplemented and b.__eq__(a) is False.