Repository navigation
from __future__ import print_function #44448
Description
| BPO | 1633807 |
|---|---|
| Nosy | @gvanrossum, @loewis, @Yhg1s, @rhettinger, @ericvsmith |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2008-03-18.23:47:20.054>
created_at = <Date 2007-01-12.07:13:37.000>
labels = ['interpreter-core']
title = 'from __future__ import print_function'
updated_at = <Date 2008-03-18.23:47:20.053>
user = 'https://bugs.python.org/anthonybaxter'bugs.python.org fields:
activity = <Date 2008-03-18.23:47:20.053>
actor = 'eric.smith'
assignee = 'none'
closed = True
closed_date = <Date 2008-03-18.23:47:20.054>
closer = 'eric.smith'
components = ['Interpreter Core']
creation = <Date 2007-01-12.07:13:37.000>
creator = 'anthonybaxter'
dependencies = []
files = ['7713', '7714', '7715']
hgrepos = []
issue_num = 1633807
keywords = ['patch']
message_count = 11.0
messages = ['51724', '51725', '51726', '51727', '51728', '51729', '51730', '51731', '51732', '63829', '64018']
nosy_count = 7.0
nosy_names = ['gvanrossum', 'loewis', 'twouters', 'nnorwitz', 'anthonybaxter', 'rhettinger', 'eric.smith']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1633807'
versions = ['Python 2.6']
Activity
anthonybaxter commentedon Jan 12, 2007
This was done partly as a learning exercise, partly just as a vague idea that might prove to be practical (chatting with Neal at the time, but all blame is with me, not him!)
The following adds 'from __future__ import print_function' to 2.x. When this is enabled, 'print' is no longer a statement. Combined with copying bltinmodule.c:builtin_print() from the p3yk trunk, this should give some compatibility options for 2.6 <-> 3.0
Note that for some reason I don't fully understand, this doesn't work in interactive mode. For some reason, in interactive mode, the parser flags get reset for each line. Wah.
anthonybaxter commentedon Jan 12, 2007
Updated version of patch - fixes interactive mode, adds builtins.print
File Added: print_function.patch
nnorwitz commentedon Jan 17, 2007
Guido, this is the patch I was talking about wrt supporting a print function in 2.6. exec could get similar treatment. You mentioned in mail that things like except E as V: can go in without a future stmt. I agree.
gvanrossum commentedon Jan 17, 2007
I don't think we need to do anything special for exec, as the exec(s, locals, globals) syntax is already (still :-) supported in 2.x with identical semantics as in 3.0.
except E as V *syntax* can go in without a future stmt; and (only when that syntax is used) it should also enforce the new semantics (V must be a simple name and is deleted at the end of the except clause).
I think Anthony's patch is a great idea, but I'll refrain from reviewing it. I'd say "just do it". :-)
Yhg1s commentedon Jan 17, 2007
You seem to have '#if 0'ed-out some code related to the with/as-statement warnings; I suggest just removing them. Since you're in this code now, it might make sense to provide a commented out warning about the use of the print statement, so we won't have to figure it out later (in Python 2.9 or when we add -Wp3yk.)
It needs a test, and probably a doc change somewhere.
anthonybaxter commentedon Jan 29, 2007
Attached version 3 of the patch.
I've added an '#if 0'd warning in ast.c - for instance, when enabled, you get
./setup.py:1336: SyntaxWarning: print no longer a statement in Py3.0
I'll make a new version of a -W py3k patch that enables this as well.
I've made the other cleanup suggested by twouters. I'm not clear on the best way to do the tests for this - the from __future__ needs to be at the start of the file. My concern is that anything that tries to compile the whole test file with this under a previous version will choke and die on the print-as-function. Not sure if this is a hugely bad problem or not.
Docs will follow once I bother wrapping my head around LaTeX and figuring out the best way to do the docs. I'm guessing we need a note in ref/ref6.tex in the section on the print statement, another bit in the same file in the subsection on Future statements, and something in lib/libbltin.tex. Did I miss anywhere?
In current 3.0, the builtin is called Print, not print. Is there a reason for this? Is it just a matter of updating all the tests and ripping out the support for the print statement and the related opcodes? If so, I'll tackle that next. Doing this does mean that the docs and the stdlib and the tests will all need a huge amount of updating, and it will make merging from the trunk to the p3yk branch much more painful.
While I'm in the vague area - why is PRINT_ITEM inlined in ceval.c? Couldn't it be punted out to a separate function, making the main switch statement just that little bit smaller? I can't imagine that making 'print' that little tiny bit faster is actually worthwhile, compared to shrinking the main switch statement.
except E as V, I'll look at later for a different patch. My tree is already getting quite cluttered already with uncommitted patches :-)
File Added: print_function.patch3
rhettinger commentedon Jan 29, 2007
Instead of __future__ imports, it would be better to put all of this Py3.0 stuff in a single compatability module and keep the rest of Py2.x as clean as possible.
anthonybaxter commentedon Jan 30, 2007
That only works for a very small number of the changes. I can't see how we could change the parser using a module.
loewis commentedon Feb 7, 2007
rhettinger: I agree with anthonybaxter; implementing this in a module to import is not possible (unless you want *another* module that works like __future__ imports, i.e. where importing it isn't just a plain import - you could then just as well require to put "this is py3k" as the first line of the file). I wish PEP-244 would have been adopted, then you could "directive python3" at the top.
As for testing: I don't see it as a problem if the test suite only works with the version where the feature is introduced. See test_future* and test_with.
As for PRINT_ITEM: it was always inlined, since day 1. It has grown since, but apparently nobody ever bothered refactoring (on day 1, it was smaller, and the bulk of it was, and still is, in writeobject aka PyFile_WriteObject)
ericvsmith commentedon Mar 18, 2008
I'm going to review Anthony's patch and attempt to get it working in the
current trunk.
I'm going to start by adding some print tests to 3.0, then backport.
ericvsmith commentedon Mar 18, 2008
Checked in as r61577.