This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Deleting __new__ does not restore previous behavior
Type: Stage: resolved
Components: Versions: Python 3.7, Python 3.5
process
Status: closed Resolution: duplicate
Dependencies: Superseder: Assigning and deleting __new__ attr on the class does not allow to create instances of this class
View: 25731
Assigned To: Nosy List: joydiamond, ppperry, steven.daprano
Priority: normal Keywords:

Created on 2018-10-29 00:16 by joydiamond, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (5)
msg328773 - (view) Author: Joy Diamond (joydiamond) Date: 2018-10-29 00:16
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__ = 0
del Color.__new__

red = Color('red')      #   Fails in Python 3; works in Python 2 & pypy
assert red.name == 'red'

This works in Python 2, pypy, but fails in Python 3 as follows:

Traceback (most recent call last):
  File "x.py", line 13, in <module>
    red = Color('red')      #   Fails in Python 3; works in Python 2 & pypy
TypeError: object() takes no parameters
msg328781 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2018-10-29 01:29
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 assigning to Color.__new__ should have failed in the first place.
msg328782 - (view) Author: Joy Diamond (joydiamond) Date: 2018-10-29 01:43
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 realistic assignment to __new__ -- this one shows we are "caching" the instance "green" -- so it is reused:

class Color(object):
    __slots__ = (('name',))

    def __init__(self, name):
        self.name = name


green = Color('green')  #   Works
assert green.name == 'green'


@staticmethod
def Color__new__cache_green(m, name):
    if name == 'green':
        return green

    return object.__new__(m, name)


Color.__new__ = Color__new__cache_green

green_2 = Color('green')
assert green_2 == green

blue = Color('blue')
assert blue.name == 'blue'

del Color.__new__

red = Color('red')      #   Fails in Python 3; works in Python 2 & pypy
assert red.name == 'red'

Finally as for `Color.__x__` assignment, this has nothing to do with `__slots__` as it is assigning to `Color`, not to an instance of `Color`.

`green.__x__ = 0` properly fails since there is no `__x__` slot:

AttributeError: 'Color' object has no attribute '__x__'
msg328792 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2018-10-29 06:05
> 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 `Color`, not to an instance of 
> `Color`.

Of course, sorry for the noise.
msg328869 - (view) Author: (ppperry) Date: 2018-10-29 20:44
This is a duplicate of issue25731
History
Date User Action Args
2022-04-11 14:59:07adminsetgithub: 79279
2018-10-30 12:41:27josh.rsetstatus: open -> closed
superseder: Assigning and deleting __new__ attr on the class does not allow to create instances of this class
resolution: duplicate
stage: resolved
2018-10-29 20:44:40ppperrysetnosy: + ppperry
messages: + msg328869
2018-10-29 06:05:24steven.dapranosetmessages: + msg328792
2018-10-29 01:43:26joydiamondsetmessages: + msg328782
2018-10-29 01:29:58steven.dapranosetnosy: + steven.daprano
messages: + msg328781
2018-10-29 00:16:25joydiamondcreate