Andrew Kuchling wrote:
IMO breaking code would be ok if we issue warnings today and implement nested scopes issuing errors tomorrow. But this is simply a statement about principles and raised impression.
Agreed. So maybe that's the best solution: pull nested scopes from 2.1 and add a warning for from...import (and exec?) inside a function using nested scopes, and only add nested scopes in 2.2, after everyone has had 6 months or a year to fix their code.
don't we have a standard procedure for this? http://python.sourceforge.net/peps/pep-0005.html Steps For Introducing Backwards-Incompatible Features 1. Propose backwards-incompatible behavior in a PEP. 2. Once the PEP is accepted as a productive direction, implement an alternate way to accomplish the task previously provided by the feature that is being removed or changed. 3. Formally deprecate the obsolete construct in the Python documentation. 4. Add an an optional warning mode to the parser that will inform users when the deprecated construct is used. 5. There must be at least a one-year transition period between the release of the transitional version of Python and the release of the backwards incompatible version. looks like we're somewhere around stage 3, which means that we're 12+ months away from deployment. Cheers /F