Add `future_builtins` as an alias for `builtins`
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. 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. I think the above actually *is* a kind of __future__ report which just happens to be in a regular module because it doesn't need any special compiler support. 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. However, I think `future_builtins` is special because it's sole raison d'être is forward-compatibility and becuase of the analogy with `__future__`. Cheers, Sven
On 5/9/2012 2:48 PM, Sven Marnach wrote:
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.
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.
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
No, because it is trivial to do the following during application startup (with appropriate version checks or try blocks): import sys, builtins sys.modules["future_builtins"] = builtins Or, use the six package instead. -- Sent from my phone, thus the relative brevity :)
On 17/05/12 08:28, Mathias Panzenböck wrote:
from __past__ import unicode_literals, future_builtins
I seem to remember Guido declaring ages ago that there would never be any imports from the past. So the past import feature would first have to be imported from a reality where he hadn't made that decision. from __alternatetimeline__ import __past__ from __past__ import unicode_literals, future_builtins -- Greg
On 5/9/2012 2:48 PM, Sven Marnach wrote:
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.
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.
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
No, because it is trivial to do the following during application startup (with appropriate version checks or try blocks): import sys, builtins sys.modules["future_builtins"] = builtins Or, use the six package instead. -- Sent from my phone, thus the relative brevity :)
On 17/05/12 08:28, Mathias Panzenböck wrote:
from __past__ import unicode_literals, future_builtins
I seem to remember Guido declaring ages ago that there would never be any imports from the past. So the past import feature would first have to be imported from a reality where he hadn't made that decision. from __alternatetimeline__ import __past__ from __past__ import unicode_literals, future_builtins -- Greg
participants (7)
-
Greg Ewing -
Jakob Bowyer -
Mathias Panzenböck -
Mike Graham -
Nick Coghlan -
Sven Marnach -
Terry Reedy