print statements get incorrectly mangled by the autocall feature under Python 2.6

Bug #414967 reported by Robert Kern
66
This bug affects 13 people
Affects Status Importance Assigned to Milestone
IPython
Fix Committed
Low
Fernando Perez
ipython (Ubuntu)
Fix Released
High
Unassigned

Bug Description

For example, from Gaël:

(python 2.6, IPython 0.9.1):

In [1]: print 1, 2, 3
------> print(1, 2, 3)
(1, 2, 3)

The problem arises because Python 2.6 provides a __builtins__.print() function for migration to Python 3.x. However, statements like "print(1,2,3)" still get parsed as a print of a tuple rather than printing threeobjects with separating spaces. A __future__ import can enable the 3.x syntax.

http://docs.python.org/whatsnew/2.6.html#pep-3105-print-as-a-function

A fix is a bit tricky, since autocall should transform such lines if the __future__ import has been made. This might be difficult to check, though.

Related branches

Revision history for this message
Beni Cherniavsky (cben) wrote :

Still happens as of 0.10 (shipped in Ubuntu Karmic).

A side effect of this bug is breaking completion under emacs when autocall is enabled.
(Emacs parses the "-------> print(...)" line as if it was the output.)
Attaching patch to ipython.el that fixes this (and will also work into 3.0 in the future).

Revision history for this message
Fernando Perez (fdo.perez) wrote :

Mmh:

- Beni, I've applied your patch to 0.10.1 and trunk-dev, thanks.

- As for the real problem with print, I'm not sure what to do: I've spent some quality time with the Python sources, trying to write some ctypes-based utilities to fish into the compiler state struct (see compiler.c and future.c in the Python tree), but no success yet. It's not the type of code I'm familiar with so it's likely to be slow/hard going, and I don't have the time for more on this now. Ultimately I'm leaning towards suggesting that people simply put in their config file

from __future__ import print_function

and be done with it! That way they start getting used to print as a function everywhere, in preparation for 3.0, they can learn the syntax of the function, and IPython will happily put the parens in there for them.

It seems like a better way to address this than to sink days of work into an obscure tool to spelunk into the compiler internals at runtime to fish a __future__ flag out...

Thoughts?

If people agree on this, closing the bug will just require adding the text above to the docs/faq.

Changed in ipython:
importance: Undecided → Low
status: New → In Progress
assignee: nobody → Fernando Perez (fdo.perez)
milestone: none → 0.11
Revision history for this message
Fernando Perez (fdo.perez) wrote :

This is really an annoying bug, but I'm a bit lost on how to approach it. For example, we could hardcode a check on 'print' being on the line to avoid triggering the autocall behavior, but that would break legitimate use of autocall for users of print as a function...

Any suggestions welcome.

Revision history for this message
Robert Kern (robert-kern) wrote :

In LineInfo.ofind(), when ifun is "print", check if the compiler has recorded the "from __future__ import print_function":

import __future__

def ofind(self, ip):
    ...
    if self.ifunc == 'print':
        if not ip.shell.compile.compiler.flags & __future__.CO_FUTURE_PRINT_FUNCTION:
            return {'found': False, 'obj': None, ...}
    ...

Revision history for this message
Fernando Perez (fdo.perez) wrote : Re: [Bug 414967] Re: print statements get incorrectly mangled by the autocall feature under Python 2.6

On Thu, Apr 22, 2010 at 11:46 AM, Robert Kern
<email address hidden> wrote:
> In LineInfo.ofind(), when ifun is "print", check if the compiler has
> recorded the "from __future__ import print_function":
>
> import __future__
>
> def ofind(self, ip):
>    ...
>    if self.ifunc == 'print':
>        if not ip.shell.compile.compiler.flags & __future__.CO_FUTURE_PRINT_FUNCTION:
>            return {'found': False, 'obj': None, ...}

Aha thanks! I looked around for this flag by reading the compiler
source code, but I failed to find this.

OK, with this info in hand, we can fix this damned bug quickly, which
is awfully irksome.

Cheers,

f

Revision history for this message
Fernando Perez (fdo.perez) wrote :
Changed in ipython:
status: In Progress → Fix Committed
Revision history for this message
Fernando Perez (fdo.perez) wrote :

Fixed 2.5 and below incompatibitliy in r1225 for 0.10.1 and r1238 for trunk.

Revision history for this message
Brian Murray (brian-murray) wrote :

Fernando - So is creating a patch out of revision 1224 the only bit we need to fix this in Ubuntu for Lucid?

Changed in ipython (Ubuntu):
status: New → Triaged
importance: Undecided → High
Revision history for this message
Fernando Perez (fdo.perez) wrote :

Hi Brian,

On Fri, Apr 23, 2010 at 10:19 AM, Brian Murray <email address hidden> wrote:
> Fernando - So is creating a patch out of revision 1224 the only bit we
> need to fix this in Ubuntu for Lucid?

Yes! I hope to release 0.10.1 in the near future officially, so you
can update to that later on.

Cheers,

f

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ipython - 0.10-1ubuntu1

---------------
ipython (0.10-1ubuntu1) lucid; urgency=low

  * cherrypicked rev 1224 and 1225 from lp:ipython/0.10.1 to fix (LP: #414967)
    """Fix autocall misfiring on print for python 2.5 and newer."""
 -- Markus Korn <email address hidden> Fri, 23 Apr 2010 20:16:11 +0200

Changed in ipython (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.