[SciPy-dev] P3 - my education [was: change print statements to print functions in docstrings]

Ryan May rmay31@gmail....
Sat Aug 15 14:43:01 CDT 2009

On Sat, Aug 15, 2009 at 1:18 PM, David Goldsmith <d_l_goldsmith@yahoo.com>wrote:

> --- On Sat, 8/15/09, Ryan May <rmay31@gmail.com> wrote:
> > As a curious "innocent bystander" that only goes
> > along with earth shattering software change "kicking
> > and screaming" ;-) why did the Python 3 PTB decide to
> > change such a fundamental construct?
> >
> >
> > One reason is that by making it a function, it's easy
> > to replace it with a different, custom function.  It also
> But isn't that the purpose an object's __str__ method being bound to print
> by default?  Unless, I guess, you want to usurp print globally; but then
> can't you still just assign your replacement to print in the top level
> namespace and be done w/it?  Personally, if I were among the PTB, I'd need
> more...

If you have print as a function, you can change it to a logging function
just by redefining print.  With print as a statement, the only way you can
get this is by using a custom printing function from the start.  Also,
__str__ doesn't put anything on the screen--it does what the name says, it
converts to a string.  That's orthogonal to the issue of print as a

> > (IMO) seems a bit more pythonic.
> Um, why?  Perhaps it stems from one's personal preference regarding the way
> one prefers to program?  Having "grown-up" a procedural programmer, I'm now
> an OO "true believer," though I feel that one of Python's greatest strengths
> is that it fully supports "going both ways"; because of that, I feel neither
> function nor method has the edge in being more Pythonic.  (I wonder,
> however, what the dominant mode is in practice - certainly OO in GUI/Event
> Driven programming, no?)

Procedural vs. OO has nothing to do with this either.  It's merely a change
from language *syntax* to a built-in function.  To me, a function seems a
more natural place for such *functionality*, not a statement/syntax.

    print a,  #Suppresses newline

    print >>file, a #Prints to fileobject a

These other uses are a bit cryptic (especially new line suppression).  These
are reminicent of Perl and aren't as expressive and explicit as modern
python.  And have you ever tried to print a bunch of things using something
other than spaces to separate them?  You *can't* without making the string
yourself.  These are warts and they only continue to exist because they date
back to early python and were very painful to change.

> > Remeber, the pain of
> > breakage was kind of the point of 3.0. :)
> Please explain.

3.0 is the time to do *any* breaking changes.  If they were ever going to
change something like this, this was the sole opportunity.  If you were
starting from scratch and not worried about the pain of changes, would you
have problems with print as a function? Would you actually favor the print
statement?  The design goal of Python 3.0 was to make the best python
possible with no mind to backwards compatibility.  As I've heard several
times, there *will not* be a 4.0 ilke this.


> DG
> PS: In recognition that this branch of this thread is OT, everyone please
> feel free to email me your thoughts off-list.
> >
> >
> >
> > Ryan
> >
> > --
> > Ryan May
> > Graduate Research Assistant
> > School of Meteorology
> > University of Oklahoma
> >
> >
> > -----Inline Attachment Follows-----
> >
> > _______________________________________________
> > Scipy-dev mailing list
> > Scipy-dev@scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev

Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20090815/78a5cc69/attachment-0001.html 

More information about the Scipy-dev mailing list