Neil Schemenauer <nas@python.ca>: > Optimization options that globally change semantics seem like a bad > idea. How would you know some module you are using will not break? I > agree with Mark that a per-module switch would be better. There's something a bit strange about this situation, though. The compiler knows whether a module shadows any of its *own* builtins, and can avoid applying the optimisation to those names. So the optimisation doesn't change the semantics of the module itself, provided some conditions are met. But those conditions depend on things *outside* the module -- namely, whether any *other* module assigns to one of this module's globals so as to shadow a builtin. This makes me think that having a flag inside the module is not the right thing to do, or at least it's not the only thing that's needed. There needs to be a way to turn the optimisation *off* from outside the affected module. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
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