[Patches] [ python-Patches-1633807 ] from __future__ import print_function

[SourceForge.net]

Patches item #1633807, was opened at 2007-01-12 08:13
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1633807&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: from __future__ import print_function

Initial Comment:
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. 

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2007-02-07 09:32

Message:
Logged In: YES 
user_id=21627
Originator: NO

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)

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2007-01-30 07:19

Message:
Logged In: YES 
user_id=29957
Originator: YES

That only works for a very small number of the changes. I can't see how we
could change the parser using a module.

from __future__ import foo is the standard way we make forwards-compatible
changes to Python. It's been that way for quite a while now - I don't see
it as being controversial at all.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-29 18:07

Message:
Logged In: YES 
user_id=80475
Originator: NO

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.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2007-01-29 13:37

Message:
Logged In: YES 
user_id=29957
Originator: YES

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

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2007-01-17 16:58

Message:
Logged In: YES 
user_id=34209
Originator: NO

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.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-01-17 16:24

Message:
Logged In: YES 
user_id=6380
Originator: NO

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". :-)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-17 08:42

Message:
Logged In: YES 
user_id=33168
Originator: NO

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.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2007-01-12 08:31

Message:
Logged In: YES 
user_id=29957
Originator: YES

Updated version of patch - fixes interactive mode, adds builtins.print

File Added: print_function.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1633807&group_id=5470