This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Remove explicit inheriting of object in class definitions
Type: Stage: resolved
Components: Library (Lib) Versions: Python 3.9
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: ju-sh, serhiy.storchaka, steven.daprano, xtreak
Priority: normal Keywords:

Created on 2020-03-21 12:40 by ju-sh, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (6)
msg364739 - (view) Author: Julin (ju-sh) * Date: 2020-03-21 12:40
In the source, many class definitions still explicitly inherit from `object` though it is no longer necessary in Python3.

Can't we change it?
msg364741 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2020-03-21 13:06
Code churn for no good reason is not a good idea. I cannot think of any good reasons to change this:

- it doesn't add new functionality;
- it doesn't fix bugs;
- it doesn't make the code easier to maintain;
- it makes the code LESS clear instead of more clear;
- PEP 8 doesn't have an opinion on whether to explicitly or implicitly inherit from object;
- but the Zen of Python ("import this") does.

Do you have any good reasons for removing the explicit inheritance from object?
msg364742 - (view) Author: Julin (ju-sh) * Date: 2020-03-21 13:30
I just thought it looked different compared to the usual code that some of us were used to. Though it is probably familiar enough to the people who actually maintain the cpython code base.

I agree with everything that you mentioned with regards to what I could understand (No new functionality, no bug fix). Not experienced enough to know about what makes code more maintainable.

Why do you think it makes the code less clear, though?
msg364744 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-03-21 13:41
We usually do not accept mass cosmetic changes. It messes the history and may break pending PRs. It also consumes the time of core developers for review and has a risk of introducing bugs.
msg364755 - (view) Author: Karthikeyan Singaravelan (xtreak) * (Python committer) Date: 2020-03-21 14:40
Previous discussion:
msg364756 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2020-03-21 14:42
On Sat, Mar 21, 2020 at 01:30:13PM +0000, Julin wrote:
> Why do you think it makes the code less clear, though?

Classes that inherit from object, and those which don't ("classic 
classes") behave differently in Python 2. But in Python 3, they are 
precisely the same.

Anyone who is familiar with Python 2, perhaps because they still have to 
deal with a legacy code base, or just because they learned using that 
version, will have to mentally adjust each time they see something which 
looks like a classic class, but actually is a new-style type.

Beginners who are only starting to learn Python may not understand the 
type hierarchy, and may believe that a class that doesn't explicitly 
inherit from object is a stand-alone class that doesn't inherit from 
object. Perhaps they have come from another language with different 
rules, or that lacks a single base object, like Python originally did.
Date User Action Args
2022-04-11 14:59:28adminsetgithub: 84213
2020-03-21 14:42:43steven.dapranosetmessages: + msg364756
2020-03-21 14:40:36xtreaksetnosy: + xtreak
messages: + msg364755
2020-03-21 13:41:47serhiy.storchakasetstatus: open -> closed

nosy: + serhiy.storchaka
messages: + msg364744

resolution: rejected
stage: resolved
2020-03-21 13:30:13ju-shsetmessages: + msg364742
2020-03-21 13:06:09steven.dapranosetnosy: + steven.daprano
messages: + msg364741
2020-03-21 12:40:37ju-shcreate