[issue35098] Deleting __new__ does not restore previous behavior

Change by Josh Rosenberg : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Assigning and deleting __new__ attr on the class does not allow to create instances of this class ___ Python tracker

[issue35098] Deleting __new__ does not restore previous behavior

ppperry added the comment: This is a duplicate of issue25731 -- nosy: +ppperry ___ Python tracker ___ ___ Python-bugs-list mailing

[issue35098] Deleting __new__ does not restore previous behavior

Steven D'Aprano added the comment: > Its quite valid to assign to __new__ to replace the behavior of how an > instance is created. Of course it is, and I never argued otherwise. > Finally as for `Color.__x__` assignment, this has nothing to do with > `__slots__` as it is assigning to

[issue35098] Deleting __new__ does not restore previous behavior

Joy Diamond added the comment: Its quite valid to assign to __new__ to replace the behavior of how an instance is created. (Obviously you would not really assign `0` to it; my example was just to show the `del Color.__new__` fails - so what was assigned was not relevant). Here is a more

[issue35098] Deleting __new__ does not restore previous behavior

Steven D'Aprano added the comment: I think the real WTF here is that you can write to arbitrary dunder attributes even if they aren't listed in __slots__. py> Color.__NOBODY_expects_the_Spanish_Inquisition__ = "What?" py> Color.__NOBODY_expects_the_Spanish_Inquisition__ 'What?' I think that

[issue35098] Deleting __new__ does not restore previous behavior

New submission from Joy Diamond : Related: https://bugs.python.org/issue5322 Consider the following program: class Color(object): __slots__ = (('name',)) def __init__(self, name): self.name = name green = Color('green') # Works assert green.name == 'green' Color.__new__