"Edward C. Jones" <edcjones at erols.com> wrote in message
news:40A8D37B.7030807 at erols.com...
> # In the code below, "a.__str__()" does not default to "a.__repr__() as
> # might be expected. It finds the "__str__" in the base class X. The
> # Reference Manual, section 3.3.1, says:
> # If a class defines __repr__() but not __str__(), then __repr__() is
> # also used when an 'informal' string representation of instances of
> # that class is required.
> # If the reader is in lawyer mode, the documentation is correct.
I don't think one has to be in lawyer mode to think that 'attribute x is
defined by class C' == 'C.x returns an object without exception', whether
the production is by direct lookup, inheritance, or calculation. It is
possible that 'defines' could be defined better.
The current behavior seems to be
try:
f = i.__str__
except AttributeError:
try:
f = i.__repr__
except AttributeError
f = <default stringifier that produces '<class instance at 0x####>'
form >
s = f(i)
Your implied and underdefined alternative would require special casing of
__str__ lookup to not use inheritance.
> # Is the current behavior what was intended? What should the behavior be?
Since the current behavior is hard to see as a bug, I think it should stay
as is, if it has been consistently so forever, even if something else might
have been once preferred.
Terry J. Reedy
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