Deleting __new__ does not restore previous behavior

[Rhodolite]

BPO	35098
Nosy	@stevendaprano, @pppery, @Rhodolite
Superseder	bpo-25731: Assigning and deleting new attr on the class does not allow to create instances of this class

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2018-10-30.12:41:27.416>
created_at = <Date 2018-10-29.00:16:25.045>
labels = ['3.7']
title = 'Deleting __new__ does not restore previous behavior'
updated_at = <Date 2018-10-30.12:41:27.415>
user = 'https://github.com/Rhodolite'

bugs.python.org fields:

activity = <Date 2018-10-30.12:41:27.415>
actor = 'josh.r'
assignee = 'none'
closed = True
closed_date = <Date 2018-10-30.12:41:27.416>
closer = 'josh.r'
components = []
creation = <Date 2018-10-29.00:16:25.045>
creator = 'joydiamond'
dependencies = []
files = []
hgrepos = []
issue_num = 35098
keywords = []
message_count = 5.0
messages = ['328773', '328781', '328782', '328792', '328869']
nosy_count = 3.0
nosy_names = ['steven.daprano', 'ppperry', 'joydiamond']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '25731'
type = None
url = 'https://bugs.python.org/issue35098'
versions = ['Python 3.5', 'Python 3.7']

[Rhodolite]

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

[stevendaprano]

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.

[Rhodolite]

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__'

[stevendaprano]

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.

[pppery]

This is a duplicate of bpo-25731