str(super()) != super().__str__()

[GuillaumeDominici]

BPO	34761
Nosy	@rhettinger, @ericsnowcurrently, @serhiy-storchaka

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2018-09-21.17:08:57.407>
created_at = <Date 2018-09-21.08:37:47.633>
labels = ['type-bug', 'invalid']
title = 'str(super()) != super().__str__()'
updated_at = <Date 2018-09-21.17:08:57.405>
user = 'https://bugs.python.org/GuillaumeDominici'

bugs.python.org fields:

activity = <Date 2018-09-21.17:08:57.405>
actor = 'eric.snow'
assignee = 'none'
closed = True
closed_date = <Date 2018-09-21.17:08:57.407>
closer = 'eric.snow'
components = []
creation = <Date 2018-09-21.08:37:47.633>
creator = 'Guillaume Dominici'
dependencies = []
files = []
hgrepos = []
issue_num = 34761
keywords = []
message_count = 3.0
messages = ['325976', '325978', '326008']
nosy_count = 4.0
nosy_names = ['rhettinger', 'eric.snow', 'serhiy.storchaka', 'Guillaume Dominici']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue34761'
versions = ['Python 3.6']

[GuillaumeDominici]

The super proxy does not seem to forward call to .__str__() when the call occurs via str() function.
It may be an expected behavior, but it looks unexpected to me.

Minimal reproduction (tested on Python 3.6, but I believe may newer versions have similar behavior):

class Parent():
  def __str__(self):
    return "Parent"

class Child(Parent):
  def foo(self):
    s = super(Child, self)
    print(s.__str__())
    print(str(s))


c = Child()
c.foo()

# Output :
### Parent
### <super: <class 'Child'>, <Child object>>

[serhiy-storchaka]

It is an expected behavior.

From https://docs.python.org/3/library/functions.html#super:

Return a proxy object that delegates method calls to a parent or sibling class of type.

super() delegates explicit method calls. You shouldn't expect that it will delegate special methods called indirectly. For example, super() + 2 doesn't call super().__add__(2), and float(super()) doesn't call super().__float__().

[ericsnowcurrently]

As Serhiy said, this is the correct behavior. Nearly all builtin operations are made using the appropriate "dunder" method from the object's type (not looked up on the object itself). So the following (based on your example) are equivalent:

  s = super(Child, self)
  print(type(s).__str__(s))
  print(str(s))

In contrast, explicitly calling __str__() on the instance involves lookup there, so the following are equivalent:

  s = super(Child, self)
  print(s.__str__())
  print(type(s).__getattribute__(s, '__str__')())

You can read more about "dunder" (AKA "special") methods and how they are looked up in the docs. [1][2][3]

I'm going to close this issue, but if you think there's anything further we can do in the documentation to avoid confusion then please let us know.

[1] https://docs.python.org/3/reference/datamodel.html#special-lookup
[2] https://docs.python.org/3/reference/datamodel.html#special-method-names
[3] https://docs.python.org/3/library/inspect.html#fetching-attributes-statically