[Python-Dev] Re: __str__ does not default to __repr__ if a base classhas __str__

Terry Reedy tjreedy at udel.edu
Mon May 17 12:15:12 EDT 2004


"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






More information about the Python-Dev mailing list