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
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