Martin v. Löwis wrote: >> Here's another thought, that perhaps is not backwards-incompatible... >> >> some_var[3] == b'd' >> >> At some point, the bytes class' __eq__ will be called -- is there a >> reason why we cannot have >> >> 1) a check to see if the bytes instance is length 1 >> 2) a check to see if >> i) the other object is an int, and >> 2) 0 <= other_obj < 256 >> 3) if 1 and 2, make the comparison instead of returning NotImplemented? > > Immutable objects that compare equal should hash equal; > so we would also have to change the hashing of byte strings. Not sure > whether that, in turn, has undesirable consequences. I thought it was the other-way-round -- if they hash equal, they should compare equal? Or is this just for immutables? > In addition, equality should be transitive, so b'A' == 65.0. I'm not sure what you're getting at... we could certainly have step 2 check for a number instead of an int, and then step 3 could extract the one element, giving an int, and then let that int compare itself with the other number, whether it be int, float, fraction, what-have-you. ~Ethan~
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4