[Python-ideas] Add `future_builtins` as an alias for `builtins`
Terry Reedy
tjreedy at udel.edu
Wed May 9 23:59:03 CEST 2012
On 5/9/2012 2:48 PM, Sven Marnach wrote:
> With the reintroduction of u"Unicode literals", Python 3.3 will remove
> one of the major stumbling stones for supporting Python 2.x and 3.3
> within the same code base.
The justification for that is that some people need *three* types of
fast string/byte literals:
1. things that should be bytes in both Py 2 and Py 3;
2. things that should be bytes in Py 2 and unicode in Py 3;
3. things that should be unicode in both Py 2 and Py;
and that there is no way to accomplish that with imports.
> Another rather trivial stumbling stone
> could be removed by adding the alias `future_builtins` for the
> `builtins` module. Currently, you need to use a try/except block,
> which isn't too bad,but I think it would be nicer if a line like
> from future_builtins import map
> continues to work, just like __future__ imports continue to work.
This proposal, as admitted above and below, does not have the
justification of the u prefix reversion. By bloating Python 3 with
obsolete stuff, it would make Python 3 less nice. I was dubious about
the u prefix addition, because I anticipated that additional, less
justified, reversion proposals would follow;-).
A strong -1
Every deprecation and removal or change of a name introduces a stumbling
block that could be 'removed' by keeping the old name. So we do not
remove things casually. This one was deprecated on introduction, so
there is no surprise. I do not see any particular reason to special case
it, and I notice that you had the sense to not propose that all
changed/deleted module names be duplicated;-).
I do not know whether this: "The 2to3 tool that ports Python 2 code to
Python 3 will recognize this usage and leave the new builtins alone" is
because 2to3 special-cases imports from future_builtins or because it
always leaves explicitly imported names alone, even if they duplicate a
built-in name. But I don't think it matters for a single code base, even
it you do use 2to3 to help write that.
In any case, if you do not like how you have to directly use
future_builtins with a single code base, wrap it. Install the
work-a-like wrapper module in either site-packages or include one in
your application package. In either case, use whatever name you prefer.
app/x.py
from app.builtins import map # or *, or whatever.
app/builtins.py:
try:
from future.builtins import *
else: # Py3
map = map
<etc>
This will work with all versions of Python 3.
> I know a few module names changed and some modules have been
> reorganised to packages, so you will still need try/except blocks for
> other imports.
If you really dislike conditional imports, you could wrap them all in an
application 'stdlib' module that hid the version details. Is something
like this really not part of existing compatibility packages?
--
Terry Jan Reedy
More information about the Python-ideas
mailing list