> 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). 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". Regards, Martin
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