"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Until just before 3.0a1, they were unequal.
I think it valuable that in the language as delivered, 'o==p' (as well as
'bool(o)' )always return True or False. Both make reasoning about code
easier since one does not have to learn and carry around in the back of
one's mind niggling exceptions. I am -1 on the last minute change and for
much the same reasons I have against building into the language
Windows-specific suppression of \r output (see pydev post).
| We decided to raise
| TypeError because we noticed many bugs in code that was doing things
| like
|
| data = f.read(4096)
| if data == "": break
|
| where data was bytes and thus the break never taken.
As G. Smith said, if a generic comparison is meant, then that should be
if not data: break
In any case, this seems like a old-code translation problem rather than a
new-code writing problem. We already know that each existing str literal
may have to be humanly checked to determine whether a 'b' should be
prepended, as would appear to be the case above.
| Similar with checks for certain magic strings (so it wasn't just empty
strings).
If a generic comparison is wanted, then "if data in ('abc', b'abc')".
If a specific comparison is wanted, then raising an exception complicates
what should be simple. Consider
def g(stuff):
if stuff == 'abc": special_text()
elif stuff == b'abc': special_bytes()
else: general_stuff(stuff)
Breaking equality is not free.
| It is also in line with the policy to refuse things like
| b"abc".replace("a", "A") or "abc".replace(b"b", b"B").
I do not see the connection. I would expect either to return TypeError,
just as
'123'.replace(1,4)
does today, even though
'1' == 1
is False, rather than exception raising.
Terry Jan Reedy
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
