[Python-Dev] str(container) should call str(item), not repr(item)
Hi,
as discussed before here:
http://mail.python.org/pipermail/python-3000/2008-May/013876.html
if you do:
>>> from decimal import Decimal
>>> a = Decimal(40)
>>> print a, a**2, a**3
40 1600 64000
>>> print [a, a**2, a**3]
[Decimal("40"), Decimal("1600"), Decimal("64000")]
>>> print {a: 3}
{Decimal("40"): 3}
>>> print {a: a**2}
{Decimal("40"): Decimal("1600")}
i.e. the str on list (and tuple and dict) calls repr() on the
elements, instead of str. This really seems to me like a bug. Because
if I wanted the repr() representation, I'd call repr() on the
list/tuple/dict. If I want a nice readable representation, I call
str(). That's the philosophy, no?
I understant there can be technical reasons why this cannot be made
into python 3.0, so why not 3.1? or 2.8?
If this cannot be made into python for some reason, how would you
suggest us we solve the following problem in sympy (symbolic
manipulation library):
>>> from sympy import Symbol, srepr
>>> x = Symbol("x")
>>> l = [x, x**2/2, x**3/3, x**4/4]
>>> str(l)
'[x, 1/2*x**2, 1/3*x**3, 1/4*x**4]'
>>> repr(l)
'[x, 1/2*x**2, 1/3*x**3, 1/4*x**4]'
>>> srepr(l)
"[Symbol('x'), Mul(Half(1, 2), Pow(Symbol('x'), Integer(2))),
Mul(Rational(1, 3), Pow(Symbol('x'), Integer(3))), Mul(Rational(1, 4),
Pow(Symbol('x'), Integer(4)))]"
As you can see, we currently have to hack our __repr__ to return the
same thing as __str__ so that things look nice in lists and
dictionaries. We provide the srepr() function that does what the
__repr__ should do instead. And as you can see, the result of srepr is
really not very readable, but it is easy to convert it back to a sympy
expression using eval. That's the purpose of repr(), no? However, you
cannot easily convert the str() back to an expression, because the
eval() doesn't know what "x" is.
One solution that we'll probably use is that we'll change our repr()
to the srepr output above, so str([x, x**2,...]) will not be pretty
and we'll use sys.displayhook to hook our own function into the
interactive session that overcomes this python behavior. This solves
the problem for interactive sessions, but it doesn't solve it if
people just call "print [x, x**2, ...]" inside their programs, for
example when debugging. Another option is to write a C extension
module that monkey patches the list class and changes the C pointer to
the (currently null) __str__ method to our own method. But I find it
very hackish and also it requires a C module.
I was discussing this with other people at EuroSciPy2008 and
everyone's first reaction that str(list) calls repr() on the elements
was that it's a bug. So was my reaction when I discovered that. So, I
think people find this highly unintuitive. So I just wanted to discuss
this more with core Python developers what you think about it and if
you also find this not very intuitive and if so, if there is any
chance to get this fixed.
Thanks,
Ondrej
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str(container) should call str(item), not repr(item)
Ondrej> i.e. the str on list (and tuple and dict) calls repr() on the Ondrej> elements, instead of str. This really seems to me like a bug. Ondrej> Because if I wanted the repr() representation, I'd call repr() Ondrej> on the list/tuple/dict. If I want a nice readable Ondrej> representation, I call str(). That's the philosophy, no? I think this is the case which calls for the distinction: >>> str(["1", "2", "3"]) "['1', '2', '3']" >>> str([1, 2, 3]) '[1, 2, 3]' If the first case did as you suggested you couldn't distinguish it from the second. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str(container) should call str(item), not repr(item)
On Mon, Jul 28, 2008 at 10:28:34AM +0200, Ondrej Certik wrote: > http://mail.python.org/pipermail/python-3000/2008-May/013876.html The PEP is pep-3140: http://python.org/peps/pep-3140.html and it has been rejected. To revive it we need better, more compelling arguments. We also need a plan for implementation that would be good enough to be accepted. Current proposals for implementation are listed in the PEP with their disadvantages. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str(container) should call str(item), not repr(item)
On Mon, Jul 28, 2008 at 10:59 AM, <[EMAIL PROTECTED]> wrote:
>
>Ondrej> i.e. the str on list (and tuple and dict) calls repr() on the
>Ondrej> elements, instead of str. This really seems to me like a bug.
>Ondrej> Because if I wanted the repr() representation, I'd call repr()
>Ondrej> on the list/tuple/dict. If I want a nice readable
>Ondrej> representation, I call str(). That's the philosophy, no?
>
> I think this is the case which calls for the distinction:
>
>>>> str(["1", "2", "3"])
>"['1', '2', '3']"
>>>> str([1, 2, 3])
>'[1, 2, 3]'
>
> If the first case did as you suggested you couldn't distinguish it from the
> second.
>
Look at this -- it seems to me that it should work fine
Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26)
>>> str("qwer")
'qwer'
>>> repr("qwer")
"'qwer'"
- Sebastian Haase
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str(container) should call str(item), not repr(item)
Another disadvantage of calling str recursively rather than repr is that it places an onus on anyone writing a class to write both a repr and a str method (or be inconsistent with the newly-accepted standard for container types). I personally write a repr method for most classes, which aids debugging. This means all my classes behave like containers currently do - their str will call repr on the items. This proposal will make all of my classes behave inconsistently with the standard container types. - Matt Giuca ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str(container) should call str(item), not repr(item)
Sebastian Haase wrote:
On Mon, Jul 28, 2008 at 10:59 AM, <[EMAIL PROTECTED]> wrote:
Ondrej> i.e. the str on list (and tuple and dict) calls repr() on the
Ondrej> elements, instead of str. This really seems to me like a bug.
Ondrej> Because if I wanted the repr() representation, I'd call repr()
Ondrej> on the list/tuple/dict. If I want a nice readable
Ondrej> representation, I call str(). That's the philosophy, no?
I think this is the case which calls for the distinction:
>>> str(["1", "2", "3"])
"['1', '2', '3']"
>>> str([1, 2, 3])
'[1, 2, 3]'
If the first case did as you suggested you couldn't distinguish it from the
second.
Look at this -- it seems to me that it should work fine
Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26)
str("qwer")
'qwer'
repr("qwer")
"'qwer'"
No it doesn't. What's happening in these examples is that the
interpreter is calling repr() on the expression result - otherwise you
wouldn't see the quotes:
>>> str("qwer")
'qwer'
>>> print str("qwer")
qwer
>>>
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str(container) should call str(item), not repr(item)
On Mon, Jul 28, 2008, Ondrej Certik wrote: > > as discussed before here: > > http://mail.python.org/pipermail/python-3000/2008-May/013876.html Precisely because this has been discussed extensively with little to show, I recommend that any further discussion be held on either python-ideas or comp.lang.python -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ Adopt A Process -- stop killing all your children! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
