Hi!
[me:]
> > or even more radical (here only for lists as an example):
> >
> > def __repr__(self):
> > result = [self.__class__.__name__, "("]
> > for item in self.data:
> > result.append(repr(item))
> > result.append(", ")
> > result.append(")")
> > return "".join(result)
Guido van Rossum:
> What's the advantage of this? It seems designed to be faster, but I
> doubt that it really is -- have you timed it? I'd go for simple --
> how time-critical can repr() be...?
I feel sorry: The example above was nonsense. I confused 'str'
with 'repr' as I quickly hacked the function above in. I erroneously
thought 'repr(some_list)' calls 'str()' on the items. If I only had
checked more carefully before, I would have remembered that indeed
the opposite is true: Currently lists don't have '__str__' and so
fall back to 'repr' on the items when 'str([....])' is used.
All this is related to the recent discussion about the new annoying
behaviour of Python 1.6 when (mis?)used as a Desktop calculator:
Python 1.6a1 (#6, Apr 3 2000, 10:32:06) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> print [0.1, 0.2]
[0.10000000000000001, 0.20000000000000001]
>>> print 0.1
0.1
>>> print (0.1, 0.2)
(0.10000000000000001, 0.20000000000000001)
>>> print (0.1, 0.2)[0]
0.1
>>> print (0.1, 0.2)[1]
0.2
So if default behaviour of the interactive interpreter would be changed
not to use 'repr()' for objects typed at the prompt (I believe Tim
Peters suggested that), this wouldn't help to make lists, tuples and
dictionaries containing floats more readable.
I don't know how to fix this, though. :-(
Regards, Peter
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4