str() for containers

[George Sakkis]

Hi all,

I find the string representation behaviour of builtin containers
(tuples,lists,d icts) unintuitive in that they don't call recursively str()
on their contents (e.g. as in Java) :

############### ############### #############

class A(object):
def __str__(self): return "a"
print A() a print [A()] [<__main__.A object at 0xa1a5c6c>] print map(str,[A()])

['a']

############### ############### #############

It's even more cumbersome for containers of containers (e.g. lists of dicts,
etc.). Of course one can (or should) encapsulate such stuctures in a class
and define __str__ to behave as expected, but why not having it by default ?
Is there a good reason for this ?

George

[Leif K-Brooks]

George Sakkis wrote:

I find the string representation behaviour of builtin containers
(tuples,lists,d icts) unintuitive in that they don't call recursively str()
on their contents (e.g. as in Java) :

They use repr(), not str():

class Foo(object): .... def __repr__(self):
.... return 'foo'
.... print Foo() foo print [Foo()]

[foo]

[Donn Cave]

In article <40******@rutge rs.edu>,
"George Sakkis" <gs*****@rutger s.edu> wrote:

I find the string representation behaviour of builtin containers
(tuples,lists,d icts) unintuitive in that they don't call recursively str()
on their contents (e.g. as in Java)

Please find last week's answers to this question at
http://groups.google.com/groups?hl=e...e7a6469ac7b40b

If you're still interested in further discussion of this
point, you could present an account of Java's approach
for the edification of those of us who don't know.

Donn Cave, do**@u.washingt on.edu

[Dan Bishop]

Donn Cave <do**@u.washing ton.edu> wrote in message news:<do******* *************** **@nntp1.u.wash ington.edu>...

In article <40******@rutge rs.edu>,
"George Sakkis" <gs*****@rutger s.edu> wrote:

I find the string representation behaviour of builtin containers
(tuples,lists,d icts) unintuitive in that they don't call recursively str()
on their contents (e.g. as in Java)

Please find last week's answers to this question at
http://groups.google.com/groups?hl=e...e7a6469ac7b40b

If you're still interested in further discussion of this
point, you could present an account of Java's approach
for the edification of those of us who don't know.

All Java classes include a toString() method (defined in the root
class java.lang.Objec t), which returns the string representation of
that object. Each of the standard collection classes in java.util
defines its toString() method to recursively call toString() on its
elements.

For example, the program

import java.util.*;
public class Foo {
public static void main(String[] args) {
List lst = new ArrayList();
lst.add("a");
lst.add("b");
lst.add("c");
System.out.prin tln(lst);
}
}

prints "[a, b, c]".

(Btw, this reminds me of something I like about Python: There are
literals for variable length arrays, so you don't have to write code
like that.)

The difference from Python's approach is that there isn't an
equivalent to Python's str/repr distinction. Obviously, when there's
only one string conversion method, you won't use the wrong one.

The other difference is that the built-in array types don't have a
meaningful toString() method, so

public class Foo {
public static void main(String[] args) {
String[] arr = {"a", "b", "c"};
System.out.prin tln(arr);
}
}

prints "[Ljava.lang.Stri ng;@df6ccd" (or something similar).

[Dan Bishop]

Donn Cave <do**@u.washing ton.edu> wrote in message news:<do******* *************** **@nntp1.u.wash ington.edu>...

In article <40******@rutge rs.edu>,
"George Sakkis" <gs*****@rutger s.edu> wrote:

I find the string representation behaviour of builtin containers
(tuples,lists,d icts) unintuitive in that they don't call recursively str()
on their contents (e.g. as in Java)

Please find last week's answers to this question at
http://groups.google.com/groups?hl=e...e7a6469ac7b40b

If you're still interested in further discussion of this
point, you could present an account of Java's approach
for the edification of those of us who don't know.

All Java classes include a toString() method (defined in the root
class java.lang.Objec t), which returns the string representation of
that object. Each of the standard collection classes in java.util
defines its toString() method to recursively call toString() on its
elements.

For example, the program

import java.util.*;
public class Foo {
public static void main(String[] args) {
List lst = new ArrayList();
lst.add("a");
lst.add("b");
lst.add("c");
System.out.prin tln(lst);
}
}

prints "[a, b, c]".

(Btw, this reminds me of something I like about Python: There are
literals for variable length arrays, so you don't have to write code
like that.)

The difference from Python's approach is that there isn't an
equivalent to Python's str/repr distinction. Obviously, when there's
only one string conversion method, you won't use the wrong one.

The other difference is that the built-in array types don't have a
meaningful toString() method, so

public class Foo {
public static void main(String[] args) {
String[] arr = {"a", "b", "c"};
System.out.prin tln(arr);
}
}

prints "[Ljava.lang.Stri ng;@df6ccd" (or something similar).

[Donn Cave]

In article <ad************ **************@ posting.google. com>,
da*****@yahoo.c om (Dan Bishop) wrote:

All Java classes include a toString() method (defined in the root
class java.lang.Objec t), which returns the string representation of
that object. Each of the standard collection classes in java.util
defines its toString() method to recursively call toString() on its
elements.

For example, the program

import java.util.*;
public class Foo {
public static void main(String[] args) {
List lst = new ArrayList();
lst.add("a");
lst.add("b");
lst.add("c");
System.out.prin tln(lst);
}
}

prints "[a, b, c]".
OK, so it's ambiguous - you don't know from the result
whether there are three elements, or two or one - if
one of the elements has its own ", ".
(Btw, this reminds me of something I like about Python: There are
literals for variable length arrays, so you don't have to write code
like that.)

The difference from Python's approach is that there isn't an
equivalent to Python's str/repr distinction. Obviously, when there's
only one string conversion method, you won't use the wrong one.
It would be fun to apply that reasoning to arithmetic
operators. Which one does Java support?
The other difference is that the built-in array types don't have a
meaningful toString() method, so

public class Foo {
public static void main(String[] args) {
String[] arr = {"a", "b", "c"};
System.out.prin tln(arr);
}
}

prints "[Ljava.lang.Stri ng;@df6ccd" (or something similar).

Ah, I can see how appealing this system would be.
What elegance!

Donn Cave, do**@u.washingt on.edu

[Dan Bishop]

Donn Cave <do**@u.washing ton.edu> wrote in message news:<do******* *************** **@nntp4.u.wash ington.edu>...

In article <ad************ **************@ posting.google. com>,
da*****@yahoo.c om (Dan Bishop) wrote:

All Java classes include a toString() method (defined in the root
class java.lang.Objec t), which returns the string representation of
that object...[big snip]
The difference from Python's approach is that there isn't an
equivalent to Python's str/repr distinction. Obviously, when there's
only one string conversion method, you won't use the wrong one.

It would be fun to apply that reasoning to arithmetic
operators. Which one does Java support?

toString() usually behaves more like Python's str than repr. An
exception is Double.toString , which returns 16 signifcant digits.

Jython uses toString() to implement both __str__ and __repr__ for Java
classes.

[John Roth]

"George Sakkis" <gs*****@rutger s.edu> wrote in message
news:40******@r utgers.edu...

Hi all,

I find the string representation behaviour of builtin containers
(tuples,lists,d icts) unintuitive in that they don't call recursively str()
on their contents (e.g. as in Java) : It's even more cumbersome for containers of containers (e.g. lists of dicts, etc.). Of course one can (or should) encapsulate such stuctures in a class
and define __str__ to behave as expected, but why not having it by default ? Is there a good reason for this ?
I don't think there's a ***good*** reason. The root of
the issue is that the str() / repr() distinction is too simplistic
for containers. The output of str() is supposed to be human
readable, and the output of repr() is supposed to be able
to round-trip through exec/eval (which is not always possible,
but should be maintained if it is.)

Human readable output from a container, however, needs
to be very clear on the distinction between the container
and the objects that are contained. It isn't always obvious
whether using str() or repr() on the contained object is the
best policy, and in some cases I suspect that something
different from either would be helpful.

The only clean solution I can see is to provide a third built-in
that provides the "right" output when a container class needs
to turn an object into a string. However, someone else
is going to have to do the work of writing up the use
cases and the PEP - I don't care enough.

John Roth
George

[Marcin 'Qrczak' Kowalczyk]

On Sat, 19 Jun 2004 08:41:56 -0400, John Roth wrote:

The only clean solution I can see is to provide a third built-in
that provides the "right" output when a container class needs
to turn an object into a string.

What is the right thing e.g. for strings?

--
__("< Marcin Kowalczyk
\__/ qr****@knm.org. pl
^^ http://qrnik.knm.org.pl/~qrczak/

[Peter Hansen]

Marcin 'Qrczak' Kowalczyk wrote:

On Sat, 19 Jun 2004 08:41:56 -0400, John Roth wrote:

The only clean solution I can see is to provide a third built-in
that provides the "right" output when a container class needs
to turn an object into a string.

What is the right thing e.g. for strings?

Exactly. ;-)