"Martin v. Loewis" wrote: > > > Now would such a change be acceptable if the optimization would > > only be triggered for builtin immuatble types on both sides of > > the "==" ? > > It may be even acceptable with the language change if the procedures > for introducing incompatible language changes are followed (i.e. add a > __future__ import in one version, and only use the optimization if the > future is imported; in the next version, decide that the future is > there). Perhaps we could approach other types in one of the next versions (after 2.3). It possible I'd like to avoid creating new syntax. I think having strings, unicode and numbers as first candidates would already go a long way. > When there is clearly no language change, the change would be > acceptable to me if it would cause no "significant" slow-down if the > optimization wasn't triggered. I assume you'll need a run-time test, > so it is likely that there is atleast a small slow-down due to the > additional test. Of course, only experiments can show whether the > slow-down is "significant". I'm sure we'll find some definition of "significant" which matches these criteria ;-) Seriously, the optimization should only be triggered for large enough if-elif-else constructs -- otherwise it's likely that the dictionary lookup would take longer than the sequential compares. By tuning the optimization trigger level we can assure that the optimization will be a net win with high probability. -- 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