A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2014-April/134343.html below:

[Python-Dev] Clarification on MRO when inheriting from builtin type.

[Python-Dev] Clarification on MRO when inheriting from builtin type.Chris Angelico rosuav at gmail.com
Mon Apr 28 05:13:53 CEST 2014
On Mon, Apr 28, 2014 at 12:59 PM, Paul Sokolovsky <pmiscml at gmail.com> wrote:
> From the output, "User" class as expected does not override
> list.append(), but does override list.__str__(). Is this behavior
> documented somewhere (complete arrangement)? What's the rationale
> behind it?

In Python 3.4 (don't know about other versions), list.__str__ doesn't
exist; when you call str([1,2,3]) it calls object.__str__. The MRO for
C is (C, list, User, object) so anything from list (eg append) takes
precedence over anything from User, but anything list doesn't have
will fall through to User before catching object.

ChrisA
More information about the Python-Dev mailing list

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