On Fri, Apr 15, 2022 at 05:41:55PM -0000, malmiteria wrote:
Sticking to the way its done "just" because it's the way it's done helps stabilising the language, but it makes it possible to miss improvements.
Overall, if there's only valid reasons to implement a change, this change doesn't break anything and there's no valid reason not to implement it,
You can't change existing behaviour without breaking things.
and this change is not "full MI", fine, we're out of full MI, what's the big deal?
The big deal is that right now there are programs which rely on Python providing MI in full generality, including class hierarchies with method conflicts. Whether they should is another question, but they do, and the interpreter resolves those conflicts for them. If you put in restrictions to MI that raises an error on method conflicts, that will break their code, and as a matter of policy that will not happen. Just because the language definition of MI is fully general doesn't mean that frameworks have to use that full generality. Zope and Plone have moved away from using MI to more composition in order to escape some of the problems they were facing. There is nothing wrong with frameworks or libraries introducing their own conventions, enforced by metaclasses or decorators or whatever you want, to implement C++ or Eiffel style restrictions on method conflicts.
Someone mentionned the "class A(B(C)):" syntax was already meaning something, i've tried a few things, but overall, most scenarios simply fail with this syntax today. The only one i could make work was "class A(namedtuple(...not a class...)):"
Right. The *syntax* B(C) means to call object B with argument C, and that applies inside class definitions too. You can't change the meaning of that syntax. It will always mean call object B with argument C. Are you aware that class definition syntax accepts arbitrary keyword arguments and passes them on to the `__init_subclass__` method?
class A(int, spam=1, eggs=2): ... pass ... Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: A.__init_subclass__() takes no keyword arguments
Right now, the only one which has meaning to the interpreter is `metaclass=expression`.
If anyone has any source / talks on that, i would love to read it.
Did you read the links to Michele Simionato's posts on Artima I posted? If not, then why should anyone bother sending you more links that you won't read? -- Steve