[SciPy-dev] change print statements to print functions in docstrings

Robert Kern robert.kern at gmail.com
Sat Aug 15 19:14:56 EDT 2009


On Sat, Aug 15, 2009 at 18:08, Gael
Varoquaux<gael.varoquaux at normalesup.org> wrote:
> On Sat, Aug 15, 2009 at 05:57:45PM -0500, Robert Kern wrote:
>> 2009/8/15 Stéfan van der Walt <stefan at sun.ac.za>:
>> > 2009/8/15 Emmanuelle Gouillart <emmanuelle.gouillart at normalesup.org>:
>> >>> At this point in this thread, I've reached the "strong opinion" that I'm +1 w/ Charles: speaking as someone who's gung-ho to make the docstrings as pedagogically useful as possible, I feel code-docstring consistency trumps this - IMO, the docstrings should not be be changed prior to the code itself being changed.
>
>> >> OK, you can revert the changes very easily as I paid attention to save
>> >> versions including only the modifications of print statements.
>
>> > Don't revert those changes.  Using "print" as a function is more
>> > consistent in style (one of the reasons it's been changed in 3.0).
>> > Doing it now saves us a lot of trouble later on.
>
>> print is simply not a function in 2.x. Abusing the Python 2.x syntax
>> to pretend like it is a function is terribly inconsistent when showing
>> Python 2.x code.
>
> Well, actually, it seems that this is not completely true in 2.6. Print
> seems to be both a statement and a builtin function (for this to work, I
> can only think that the Python devs added some custom logic to the
> parser). This is what confuses IPython. The strange thing is that they
> behave differently. You can test this outside of IPython.

No, it is *not* a function in Python 2.x. There is no custom logic.
The fact that "print(1,2,3)" executes is a side effect of the grammar
not requiring a spacing between "print" and the expression "(1,2,3)".
It is equivalent to "print (1,2,3)" in Python 2.x and "print((1,2,3))"
in Python 3.x. Note that it is *not* equivalent to "print(1,2,3)" in
Python 3.x.

The special support for print as a function in Python 2.6 is *only*
active when one does a __future__ import.

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

> So you are advocating no transition period between print as a statement,
> and print as a function, because if we are going to bite a bullet, we
> might as well understand what we bite, right?

Yes.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco



More information about the SciPy-Dev mailing list