"Martin v. Loewis" wrote: > > > I don't think you need anything extra if the RHS of the == is a hashable > > literal of some sort and the LHS is always the same simple variable or > > subscript expression. If the compiler can recognize the structure (that may > > be a big "if"), all you need is a dictionary of offsets stored in the > > function's constants. You just execute the equivalent of > > > > offset = jumptable.get(x, E) > > That won't work: It maybe that x is not hashable, even though it > compares equal with the RHS values. > > Even if it was hashable, you'd change the language semantics: In the > original code, you call __cmp__, say, 20 times; in the modified code, > you call __hash__ once and __cmp__ perhaps also once. If __cmp__ has > side effects, you get a language change. Good point. Now would such a change be acceptable if the optimization would only be triggered for builtin immuatble types on both sides of the "==" ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
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