print attitude
Andy Jewell
> One detail I found, don't now if it's ok:
>
> Python 2.1.1 (#4, Mar 8 2002, 12:32:24)
> [GCC 2.95.3 20010315 (release)] on sunos5
>
> >>> a = 'ñ'
> >>> a
>
> '\xf1'
>
> >>> print a
>
> ñ
>
> >>> l = ['ñ']
> >>> l
>
> ['\xf1']
>
> >>> print l
>
> ['\xf1']
>
>
> Is this OK?
>
> Why this different behaviour?
>
> Thank you!
>
> . Facundo
Facundo,
Short answer:
'ñ' is not in 7-bit ASCII, so python 'escapes' it, to it's hex value, when
evaluating it. ['ñ'] is a list, containing 1 string, and when displaying
lists (and other containers), python displays the escaped contents, as this
is the only way that 'makes sense'.
Long answer:
Remember, everything in Python is an Object, so...
>>> a=1 # and 'int' object, with the name 'a'
When you use print, it calls the __str__ method of the object you are
printing, which returns the 'string representation' of the object's data:
>>> print a
1
>>> print str(1)
1
When you just 'evaluate' the expression on the python command-line, the
__repr__ method of the object is called, which returns a 'quoted' string,
that can be used to re-create the object with the same value. For some types
(integers and floats), str(n) == repr(n) - their string representation is the
same as their quoted representation. For other types (strings for instance),
str(s) != repr(s)
>>> a
1
>>> repr(a)
1
>>> s="hello"
>>> print s
hello
>>> print str(s)
hello>>> ord("ñ")
UnicodeError: ASCII encoding error: ordinal not in range(128)
>>> print repr(s)
'hello'
If the object is a 'container' object - a list, tuple or dict, for example,
their __str__ method returns the same as their __repr__ function: a string
which can be used to recreate the object. So when you ask python to print
it, what you see is it's 'quoted' representation. How else would you print a
list? a dict? It only makes sense to print the 'quoted' version in these
cases.>>> ord("ñ")
UnicodeError: ASCII encoding error: ordinal not in range(128)
Ok - that covers a the mechanics, but what about your 'ñ'? Well, that's not a
standard 7-bit ASCII character. Python is '7-bit ASCII clean' - which means
it ONLY uses characters 0-127 in program code. Programs can manipulate any
character code, but you can't write them in python /directly/:
(on my box i get this):
>>> ord("ñ")
UnicodeError: ASCII encoding error: ordinal not in range(128)
I notice you're using an older version of Python than me (2.1.1) - I believe
this *does* allow coded over 127 (but I'm not sure of the rules).
Right, when you ask python to print a list like ['ñ'], it simply prints the
'quoted' data in it data structure. As 'ñ' > chr(127), it 'escapes' it to
it's hex value '\xf1'.
If I've got any of that wrong/inaccurate, I'm sure one of the Kindred will
correct me :-)
hope that helps
-andyj
Batista, Facundo
Erik Max Francis
> Is this OK?
>
> Why this different behaviour?
It's str vs. repr, and unfortunately it generates no end of confusion.
Let's make a simple object so we can clearly see the difference:
>>> class Display:
... def __str__(self): return '(str)'
... def __repr__(self): return '(repr)'
...
>>> d = Display()
>>> str(d)
'(str)'
>>> repr(d)
'(repr)'
So whether the str or repr of the object is called, we can tell the
difference. Now, consider:
>>> print d
(str)
>>> d
(repr)
>>> [d]
[(repr)]
>>> print [d]
[(repr)]
Printing an object prints its str, but simply specifying it as the value
of an expression in the interactive interpreter prints the repr. What
you're seeing is that both the str _and_ the repr of builtin container
types print the _repr_ of their elements. I consider this something of
a wart, but the rationalization is that it might be confusing if the str
were used when using (say) list.__str__ since it might contain spaces or
commas itself.
>>> [' ', 'a, b', 'c', ' ']
[' ', 'a, b', 'c', ' ']
If that were the str of the elements, it might be confusing:
>>> '[%s]' % ', '.join(map(str, [' ', 'a, b', 'c', ' ']))
'[ , a, b, c, ]'
I see the reasoning, but I'm not sure the benefit of the decision
outweighs the confusion it constantly calls. (This, along with standard
floating point equality questions, are probably the most frequently
asked questions about Python.)
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ But since when can wounded eyes see / If we weren't who we were
\__/ Joi
Donn Cave
Erik Max Francis <m...@alcyone.com> wrote:
...
> Printing an object prints its str, but simply specifying it as the value
> of an expression in the interactive interpreter prints the repr. What
> you're seeing is that both the str _and_ the repr of builtin container
> types print the _repr_ of their elements. I consider this something of
> a wart, but the rationalization is that it might be confusing if the str
> were used when using (say) list.__str__ since it might contain spaces or
> commas itself.
>
> >>> [' ', 'a, b', 'c', ' ']
> [' ', 'a, b', 'c', ' ']
>
> If that were the str of the elements, it might be confusing:
>
> >>> '[%s]' % ', '.join(map(str, [' ', 'a, b', 'c', ' ']))
> '[ , a, b, c, ]'
>
> I see the reasoning, but I'm not sure the benefit of the decision
> outweighs the confusion it constantly calls. (This, along with standard
> floating point equality questions, are probably the most frequently
> asked questions about Python.)
Speaking of floats, I believe lists containing floats are the main
case where people really resist seeing the sense in this - but it's
easier to call that a wart in float's repr, since they're as bugged
wherever they see it and in my opinion rightly so.
I think some time back, Steven Taschuk proposed to submit a rewrite
of the str & repr documentation, and if that goes well it should be
more or less explain the behavior of repr(list) without having to
mention it specifically. Then that would make this kind of question
an opportunity to clear up a whole area of confusion. Questions
about a thing don't immediately indicate that it's ill conceived -
I guess you have to consider how many questions there would be about
the alternative.
Donn Cave, do...@u.washington.edu
Erik Max Francis
> Speaking of floats, I believe lists containing floats are the main
> case where people really resist seeing the sense in this - but it's
> easier to call that a wart in float's repr, since they're as bugged
> wherever they see it and in my opinion rightly so.
Personally, I think the internal difference between str and repr hits
right upon a proper difference: str is for a "reasonable"
human-readable representation, and repr is for as faithful and
informative a representation as possible. These both have their uses
and I approve of the distinction.
The confusion, in my opinion, comes from the fortuity of when str vs.
repr is used, which is easy to understand once you've been exposed to it
but is very confusing at first. Even for someone who's familiar with
the inaccuracy of floating point, you can very easily see how someone
would be confused and worried about the following code fragment:
>>> x = 1.4
>>> print x
1.4
>>> print [x]
[1.3999999999999999]
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ We're here to preserve democracy, not to practice it.
\__/ Capt. Frank Rasmey
Donn Cave
Erik Max Francis <m...@alcyone.com> wrote:
> Donn Cave wrote:
>
> > Speaking of floats, I believe lists containing floats are the main
> > case where people really resist seeing the sense in this - but it's
> > easier to call that a wart in float's repr, since they're as bugged
> > wherever they see it and in my opinion rightly so.
>
> Personally, I think the internal difference between str and repr hits
> right upon a proper difference: str is for a "reasonable"
> human-readable representation, and repr is for as faithful and
> informative a representation as possible. These both have their uses
> and I approve of the distinction.
>
> The confusion, in my opinion, comes from the fortuity of when str vs.
> repr is used, which is easy to understand once you've been exposed to it
> but is very confusing at first. Even for someone who's familiar with
> the inaccuracy of floating point, you can very easily see how someone
> would be confused and worried about the following code fragment:
>
> >>> x = 1.4
> >>> print x
> 1.4
> >>> print [x]
> [1.3999999999999999]
Maybe it isn't time to wade back into this, only to repeat
ad nauseum the same old discussion. My point is that there
is a way to look at str vs. repr that 1) doesn't use utterly
ambiguous phrases like "reasonable" or "human-readable", and
2) makes it more or less self-evident that list will repr its
contents. For more, see 61-message thread
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=uw1i4nqpl33h.1
l3wpteil4jb0.dlg%4040tude.net&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%
3DUTF-8%26selm%3Duw1i4nqpl33h.1l3wpteil4jb0.dlg%254040tude.net
Donn Cave, do...@u.washington.edu
Steven Taschuk
[...]
> I think some time back, Steven Taschuk proposed to submit a rewrite
I did. See
<http://www.python.org/sf/727789>
I am not entirely satisfied with the text (suggestions welcomed);
I haven't taken the time to look at the matter again.
--
Steven Taschuk 7\ 7'Z {&~ .
stas...@telusplanet.net Y r --/hG-
(__/ )_ 1^1`
Donn Cave
Steven Taschuk <stas...@telusplanet.net> wrote:
> Quoth Donn Cave:
> [...]
> > I think some time back, Steven Taschuk proposed to submit a rewrite
> > of the str & repr documentation, [...]
>
> I did. See
> <http://www.python.org/sf/727789>
> I am not entirely satisfied with the text (suggestions welcomed);
> I haven't taken the time to look at the matter again.
Well, I see I never did convince you to try to describe
the intent of str directly.
Donn Cave, do...@u.washington.edu
Steven Taschuk
> > <http://www.python.org/sf/727789>
>
> Well, I see I never did convince you to try to describe
> the intent of str directly.
You did, but that text was written before my, er, conversion to
that point of view.
--
Steven Taschuk stas...@telusplanet.net
"I tried to be pleasant and accommodating, but my head
began to hurt from his banality." -- _Seven_ (1996)