[Python-Dev] future_builtins (was: Backporting PEP 3127 to trunk)

[Eric Smith]

Georg Brandl wrote:
> Eric Smith schrieb:
>> Guido van Rossum wrote:
>>> I wonder if, in order to change the behavior of various built-in
>>> functions, it wouldn't be easier to be able to write
>>>
>>> from future_builtins import oct, hex  # and who knows what else
>> This makes sense to me, especially if we have a 2to3 fixer which removes 
>> this line.  I'll work on implementing future_builtins.
> 
> Will the future map and filter also belong there (and if they are imported
> from future_builtins, 2to3 won't put a list() around them)?

I can certainly do the mechanics of adding the new versions of map and 
filter to future_builtins, if it's seen as desirable.

Maybe we could have 2to3 not put list() around map and filter, if 
there's been an import of future_builtins.  I realize that there are 
pathological cases where 2to3 doesn't know that a usage of map or filter 
would really be the generator version from future_builtins, as opposed 
to the actual list-producing builtins.  But would it be good enough to 
take an import of future_builtins as a hint that the author was aware 
that 2to3 wasn't going to change map and filter?

Still an open issue in my mind is adding a -3 warning to oct and hex, 
and now conceivably map and filter.  Would that be going too far?

Eric.