[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