Guido van Rossum wrote:
> On 9/9/05, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>>Any possibility to add one (or more) __future__ statement to
>>implicitly get this behavior? Any suggestion about naming?
>
>
> For the builtins, it would actually be possible to do this by simply
> importing an alternate builtins module. Something like
>
> from future_builtins import min, max, zip, range
>
> For methods on standard objects like dicts it's not really possible
> either way; the type of a dict is determined by the module containing
> the code creating it, not the module containing the code using it.
However, such a "future_builtins" module could still include modified versions
of those standard objects - such "future-proofed" code would simply still need
to deal with the fact that other libraries or clients may pass in the
old-style components (e.g. just as unicode-aware code needs to deal with the
fact that other libraries or clients may produce 8-bit strings rather than
unicode text).
Also, an alternative to changing the builtins piecemeal would be to have
"__python3_builtin__" in sys.modules and do:
try:
import __python3_builtin__
__builtins__ = __python3_builtin__
except ImportError:
# What you do here depends on whether or not __python3_builtin__
# stays around in Py3k or not.
You could then write a script to extract all known changes to the Py3k
builtins by looking for differences between the two modules.
Another trick would be to have an "everything in Python 3" option for any
syntax changes too:
from __future__ import __python3__
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
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