[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Guido van Rossum added the comment: At this point I think it's worth filing a new bug proposing to deprecate 1-arg super(), pointing out the broken usages that search found. -- ___ Python tracker

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Géry added the comment: > Anthony Sottile provided this search to showing that at least a few popular > projects are using the one argument form of super(): Thanks for the link. But it gives lots of false positives. Only two popular projects (> 1k stars) use autosuper (urwid and evennia):

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Raymond Hettinger added the comment: > any objections before I propose the removal of one-argument super? AFAICT there is nothing to be gained by deprecating the one argument form. Because it has been stable API for two decades, removing it is guaranteed to cause some disruption. So why

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Géry added the comment: Alright, thanks. Raymond, any objections before I propose the removal of one-argument super? -- ___ Python tracker ___

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Guido van Rossum added the comment: Yeah, I see no description of what you can do with an unbound super object in the docs (https://docs.python.org/3/library/functions.html#super), and experimentation with it does not reveal any useful functionality. You may want to open a new issue for

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Géry added the comment: By the way: > I don't think we need two ways to do it. So do you think we could drop the support for single-argument super? Michele said in his article: > There is a single use case for the single argument syntax of super that I am > aware of, but I think it gives

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Guido van Rossum added the comment: Thanks, let's close the issue as "won't fix". -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Géry added the comment: > On StackOverflow, there has been some mild interest in the interactions > between super() and classmethod(): > > * https://stackoverflow.com/questions/64637174 > * https://stackoverflow.com/questions/1269217 > * https://stackoverflow.com/questions/1817183 Another

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Géry added the comment: Thanks for the review. @rhettinger > And adding classmethod() support in super_descr_get() would create tight > coupling where there should be separate concerns (no other descriptor call is > classmethod specific). The descriptors `super`, `property`, and functions

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Guido van Rossum added the comment: So IIUC the "autosuper" idea is to assign a special instance of super to self.__super, so that you can write self.__super.method(...) to invoke a super method, using the magic of __private variables, instead of having to write super(classname,

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Raymond Hettinger added the comment: Will leave this open for a few days to see if anyone else steps forward to make a case for or against this proposal. -- assignee: -> rhettinger versions: -Python 3.10, Python 3.9 ___ Python tracker

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Guido van Rossum added the comment: I’m sorry, my brain hurts when trying to understand my own code for super. Hopefully someone younger can look at this.-- --Guido (mobile) -- ___ Python tracker

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Raymond Hettinger added the comment: Guido, what do you think about this proposal? Personally, I'm dubious about changing the meaning of the arguments between code paths. The callee has no way to distinguish which meaning was intended. And adding classmethod() support in

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Géry added the comment: Apologies for the long delay. > Do we have any meaningful examples to show that this is desired and useful? A use case of `super()` in a `classmethod` that comes to mind is for parameterized factory methods. It is a variation of the classic factory method design

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Raymond Hettinger added the comment: Do we have any meaningful examples to show that this is desired and useful? The primary use case for classmethods is to serve as alternate constructors that return new instances. That doesn't really lend itself to extending in a subclass. User's can

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Change by Raymond Hettinger : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

Change by Géry : -- keywords: +patch pull_requests: +24660 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26009 ___ Python tracker ___

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods

New submission from Géry : A use case of one-argument `super` (aka unbound `super`) is Guido van Rossum’s autosuper described in his 2002 article [*Unifying types and classes in Python 2.2*](https://www.python.org/download/releases/2.2.3/descrintro/#cooperation). It works with functions, but