Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Patch-adding __init__ in a class takes no effect when called from a subinterpreter #90192

Closed
hroncok mannequin opened this issue Dec 10, 2021 · 3 comments
Closed

Patch-adding __init__ in a class takes no effect when called from a subinterpreter #90192

hroncok mannequin opened this issue Dec 10, 2021 · 3 comments
Labels
3.10 only security fixes 3.11 only security fixes topic-subinterpreters type-bug An unexpected behavior, bug, or error

Comments

@hroncok
Copy link
Mannequin

hroncok mannequin commented Dec 10, 2021

BPO 46034
Nosy @vstinner, @ericsnowcurrently, @hroncok

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 2021-12-10.12:29:40.628>
created_at = <Date 2021-12-10.12:01:00.299>
labels = ['expert-subinterpreters', 'type-bug', '3.10', '3.11']
title = 'Patch-adding __init__ in a class takes no effect when called from a subinterpreter'
updated_at = <Date 2021-12-10.12:29:40.628>
user = 'https://github.com/hroncok'

bugs.python.org fields:

activity = <Date 2021-12-10.12:29:40.628>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2021-12-10.12:29:40.628>
closer = 'vstinner'
components = ['Subinterpreters']
creation = <Date 2021-12-10.12:01:00.299>
creator = 'hroncok'
dependencies = []
files = []
hgrepos = []
issue_num = 46034
keywords = []
message_count = 3.0
messages = ['408196', '408199', '408200']
nosy_count = 3.0
nosy_names = ['vstinner', 'eric.snow', 'hroncok']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue46034'
versions = ['Python 3.10', 'Python 3.11']

@hroncok
Copy link
Mannequin Author

hroncok mannequin commented Dec 10, 2021

Hello,

based on some bug reports reported in:

I have isolated the following reproducer that shows a regression in Python 3.10+. It happens at least with 3.10.0, 3.10.1 and 3.11.0a2. It works as expected in Python 3.9.

The following code is valid and works on 3.9, 3.10, 3.11:

=========================================

class Greeting():
    pass

def new_init(inst, name):
    inst.text = f"Hello, {name}\n"

Greeting.__init__ = new_init

Greeting("Miro")

=========================================

But if we run it via a subinterpreter, it breaks on 3.10+:

=========================================

import _testcapi

code = r"""class Greeting():
    pass

def new_init(inst, name):
    inst.text = f"Hello, {name}\n"

Greeting.__init__ = new_init

Greeting("Miro")"""

_testcapi.run_in_subinterp(code)

=========================================

$ python3.9 reproducer.py
(exits cleanly)
$ python3.10 reproducer.py 
Traceback (most recent call last):
  File "<string>", line 9, in <module>
TypeError: Greeting() takes no arguments

$ python3.11 reproducer.py 
Traceback (most recent call last):
  File "<string>", line 9, in <module>
TypeError: Greeting() takes no arguments

My observation also shows that if the Greeting class already had (any) __init__:

=========================================

class Greeting():
    __init__ = ...

=========================================

It works as expected on 3.9, 3.10, 3.11.

In reality, this is most likely to affect classes with decorators, like:

=========================================

import attr

@attr.s
class TestClass:
    foo = attr.ib()

TestClass("Miro")

=========================================

This works standalone, but fails in a subinterpreter:

$ python3.10 reproducer.py 
Traceback (most recent call last):
  File "<string>", line 7, in <module>
TypeError: TestClass() takes no arguments

@hroncok hroncok mannequin added 3.10 only security fixes 3.11 only security fixes topic-subinterpreters type-bug An unexpected behavior, bug, or error labels Dec 10, 2021
@hroncok
Copy link
Mannequin Author

hroncok mannequin commented Dec 10, 2021

git bisect gives:

ea25180

@vstinner
Copy link
Member

I mark this issue as a duplicate of bpo-46006. It's not exactly the same issue, but the root cause is the same: in some functions, Python use fast pointer comparisons when two strings are interned, but this now fails if two interned strings belong to two different interpreters.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.10 only security fixes 3.11 only security fixes topic-subinterpreters type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

1 participant