[issue32768] object.__new__ does not accept arguments if __bases__ is changed

Ethan Furman added the comment: A use-case for writable bases: __init_subclass__ is called in type.__new__, which means that for Enum __init_subclass__ is called before the members have been added. To work around this I am currently (3.10) adding in a _NoInitSubclass to the bases before

[issue32768] object.__new__ does not accept arguments if __bases__ is changed

Alexey Muranov added the comment: There were problems with the use case for mutable bases that i posted (see #36827). Here is an updated version: https://gist.github.com/alexeymuranov/04e2807eb5679ac7e36da4454a58fa7e -- ___ Python tracker

[issue32768] object.__new__ does not accept arguments if __bases__ is changed

Alexey Muranov added the comment: Here is a use case for writable bases: https://stackoverflow.com/q/56007866 class Stateful: """ Abstract base class for "stateful" classes. Subclasses must implement InitState mixin. """ @staticmethod def __new__(cls, *args,

[issue32768] object.__new__ does not accept arguments if __bases__ is changed

Alexey Muranov added the comment: IMO "overriding" a method with itself should not change the behaviour. So it seems to me that the following is a bug: class C: def __init__(self, m): print(m) class D: @staticmethod def

[issue32768] object.__new__ does not accept arguments if __bases__ is changed

Nick Coghlan added the comment: >From VA's description of the intended use case, this actually sounds a bit >like a variant of https://bugs.python.org/issue29944: one reason that >replacing C with a new dynamically constructed type won't work reliably is >because some of

[issue32768] object.__new__ does not accept arguments if __bases__ is changed

Guido van Rossum added the comment: I fear that this is one of those cases that will longer in the tracker forever. We probably shouldn't have allowed assignment to __bases__, and the behavior is slightly surprising, but fixing it would be too complicated and there's not

[issue32768] object.__new__ does not accept arguments if __bases__ is changed

VA added the comment: The use case is a little more complex. I have a plugin system, with abstract interfaces. Plugins can't import each other, but plugins should be able to allowed to depend on another plugin (using string codes, still no direct imports), and even

[issue32768] object.__new__ does not accept arguments if __bases__ is changed

Nick Coghlan added the comment: I'd also ask whether the use case can be satisfied by rebinding __class__ instead of __bases__. That's far better defined than replacing the contents of the bases list and attempting to dynamically recalculate the MRO. --

[issue32768] object.__new__ does not accept arguments if __bases__ is changed

Guido van Rossum added the comment: Yeah, I think the use case for assigning to __bases__ has not been shown. I believe we've seen other situations where the initial list of base classes is used in some computation that affects how the class works, so I doubt it has ever

[issue32768] object.__new__ does not accept arguments if __bases__ is changed

Change by R. David Murray : -- nosy: +r.david.murray ___ Python tracker ___ ___

[issue32768] object.__new__ does not accept arguments if __bases__ is changed

Nick Coghlan added the comment: I've added Guido to the thread, as my initial reaction is to propose deprecating writable __bases__ rather than trying to support it properly. However, if we do decide to fix it, then the potential path to resolution I would suggest is: 1.

[issue32768] object.__new__ does not accept arguments if __bases__ is changed

Serhiy Storchaka added the comment: The problem is that class C(B): pass C.__bases__ = (A,) and class C(A): pass are not fully equivalent. In the first case type->tp_new != object_new. -- components: +Interpreter Core nosy:

[issue32768] object.__new__ does not accept arguments if __bases__ is changed

New submission from VA : object.__new__ takes only the class argument, but it still accepts extra arguments if a class doesn't override __new__, and rejects them otherwise. (This is because __new__ will receive the same arguments as __init__ but __new__ shouldn't need