rustompmody at gmail.com
Fri Oct 10 16:24:06 CEST 2014
On Friday, October 10, 2014 12:48:20 PM UTC+5:30, Steven D'Aprano wrote:
> Rustom Mody wrote:
> > On Thursday, October 9, 2014 10:26:41 AM UTC+5:30, Steven D'Aprano wrote:
> >> On Wed, 08 Oct 2014 19:34:30 -0700, Rustom Mody wrote:
> >> >>>> Color.Red
> >> >>>> print (Color.Red)
> >> > Color.Red
> >> > # Not sure what to make of that distinction...
> >> That's because the interactive interpreter displays the repr() of objects
> >> (except for None, which it suppresses), while print outputs the str() of
> >> them.
> > Yeah...
> > What I meant to wonder upon was: "Is this behavior what the pro-print or
> > the anti-print folks like?"
> Python's print is a tool, not a political party or religion. I'm no
> more "pro-print" than I'm "pro-len" and "anti-float". I use it when
> appropriate, and don't use it when it isn't.
Yeah... in an ideal world politics and science/technology would be separable
if not completely separate. I dont see such a world (round me at least).
See (particularly section 2):
> > In any case that the P in REPL is not *exactly* the same as print
> The "P" in Read Eval Print Loop no more stands for Python's print function
> (or statement, in 2.x) than the "R" stands for Perl's read(), the "E" for
> Lisp's eval, or the L for, um, whatever concrete example of a function
> called "loop" we can come up with. It's a generic term that describes the
> actions of the interactive environment, not the specific semantics used.
> > (or equivalently the distinction between str and repr) makes for some
> > intricate noob confusions.
> That's not to say that it categorically never happened. I'm sure that
> *somewhere* there is somebody who is confused. There probably is one or two
> newbies out there who lie awake at night wondering why the output of print
> looks different from the output in the interactive interpreter. But I do
> not believe that this is a widespread problem.
I think Ive seen a number of confusions on this list from the fact
that None quietly disappears at REPL top level and no where else.
Yeah this is no str vs repr but print statement/expression vs REPL-print.
> I've been reading this mailing list / newsgroup, and the tutor mailing list,
> for over a decade, and I don't recall ever seeing a newbie confused by the
> difference between str() and repr(), or why print uses one and the
> interactive interpreter the other. I've seen the odd question about it, but
> I wouldn't call it "confused".
Count me as noob then!
are some explanations:
repr -- should be unambiguous
str -- should be human readable
repr for developers
str for customers
More telling comments from Alex (same SO post)
1. Both have mostly useless default implementations
2. if you override __repr__, that's ALSO used for __str__, but not vice versa
3. despite the words on the subject found in typical docs, hardly
anybody bothers making the __repr__ of objects be a string that
eval may use to build an equal object (it's just too hard, AND not
knowing how the relevant module was actually imported makes it
actually flat out impossible).
If you dont find all this confusing, I am reminded of Schrödinger (or
one of his ilk):
If you dont find Quantum physics confusing you've not begun to understand it
For myself: Yeah I understand the philosophy (vaguely)
Exact detailed differences -- I never remember.
In particular when which is called.
Also which defaults to the other.
In any case when teaching beginners, I dont want to have anything to
do with repr. Just as a teacher of school arithmetic does not
generalize arithmetic to Rings and Fields
More information about the Python-list