Hi. I've replied to the first e-mail on this thread, more than 10 days ago.
I am back, though I've read most of what was written.

I don't think things have improved, but you sure are consuming everyone's time

You are still repeating this:
"more in line with the expectation of the majority, "

Though, as already asked, there is zero (nothing) to support that.
I've seen exactly _one_ e-mail among those in the thread, that seemed
to need something different from the current status quo - though not
exactly what you offer. I replied in private as that user's needs could
be fulfilled with a custom metaclass, offering personal help with that (and did not get a reply).

So, I'd suggest to you, if not for others, at least for myself, that you'd get some
backup on what this "majority" you claim could be. Could you set, I don't know,
some online form? With questions like: 

"on the following scenario, what do you [think|prefer] 'super' [does|could do]?"

Then we can check. No need for "majority" - get at least some 10 respondents, with 2 or 3 of those
thinking the same as you, and then maybe it would make sense insisting
on this path, as there could be something in there. 

Otherwise, just admit these are some features you thought of yourself, and not even you seem
to be quite sure  of which should be the specs or deterministic outcome (if any) when
calling parent class methods with M.I. Get your ideas out into some packages,
gists, blog posts - some of what you want can be got with custom metaclasses
(except when retrieving dunder methods for operators, like __add__), and I can
even help you to come up with those if you want. But these are toys nonetheless,
which might see the "light of the day" maybe once a year in a codebase.

best regards,

    js
  -><-



On Thu, Apr 7, 2022 at 12:39 PM malmiteria <martin.milon@ensc.fr> wrote:
Antoine Rozo writes:
> If the only feature you need from super is the proxy one, why don't you
> code your own parent-proxy-type?

I did : https://github.com/malmiteria/super-alternative-to-super/blob/master/parent.py

This is irrelevant to the discussion we're having i think.
Essentially, I'm arguing against today's state of some edge case of MRO + super, and against the UX associated with it.
Those are issues with today's python, and the update that i propose would reduce the UX problems with super and MRO, would allow for use case of super more in line with the expectation of the majority, and would open the door to a few cases locked behind MRO errors today.
Technically, with my proposal, you could even do circular inheritance, which is definitely unheard of today:
```
class Day:
  def tell_time(self):
    print("it's daytime")
    sleep(10000)
    super().tell_time()

class Night(Day):
  def tell_time(self):
    print("it's night time")
    sleep(10000)
    super().tell_time()

Day.__bases__ = (Night, )

Day().tell_time() # infinitely loops over "it's daytime" and "it's night time"
```
That would be an incredibely easy way to articulate process that repeat in a cycle, with no end, cron style.
No need to get multiple class too:
```
class CronTask:
  def task(self):
    # do something
    time.sleep(10000)
    super().task()

CronTask.__bases__ = (CronTask, )

CronTask().task() # runs the task forever with a time sleep in between
```

I'm convinced there's some smart designs that are banned from python because of MRO and super's limitations.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BKFSLLICTCAYBPIZBTVW4Y4OPT3UKBZ2/
Code of Conduct: http://python.org/psf/codeofconduct/