[Python-Dev] Prospective Peephole Transformation
tim.peters at gmail.com
Sat Feb 19 03:06:45 CET 2005
> The problem with the transformation was that it didn't handle the case
> where x was non-hashable and it would raise a TypeError instead of
> returning False as it should.
I'm very glad you introduced the optimization of building small
constant tuples at compile-time. IMO, that was a pure win.
I don't like this one, though. The meaning of "x in (c1, c2, ...,
c_n)" is "x == c1 or x == c2 or ... or x == c_n", and a
transformation that doesn't behave exactly like the latter in all
cases is simply wrong. Even if x isn't hashable, it could still be of
a type that implements __eq__, and where x.__eq__(c_i) returned True
for some i, and then False is plainly the wrong result. It could also
be that x is of a type that is hashable, but where x.__hash__() raises
TypeError at this point in the code. That could be for good or bad
(bug) reasons, but suppressing the TypeError and converting into False
would be a bad thing regardless.
> That situation arose once in the email module's test suite.
I don't even care if no code in the standard library triggered a
problem here: the transformation isn't semantically correct on the
face of it. If we knew the type of x at compile-time, then sure, in
most (almost all) cases we could know it was a safe transformation
(and even without the hack to turn TypeError into False). But we
don't know now, so the worst case has to be assumed: can't do this
one now. Maybe someday, though.
More information about the Python-Dev