Skip to content

Unnecessary specialization failures of LOAD_ATTR and STORE_ATTR when attributes are shadowed by the object's class. #123040

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

Closed
markshannon opened this issue Aug 15, 2024 · 3 comments
Labels
3.14 bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage

Comments

@markshannon
Copy link
Member

markshannon commented Aug 15, 2024

This applies to both instances and classes.
If an object and it's class both have attributes with the same name, this prevents specialization of access to the object's attribute.
However, in this case specialization should only be prevented if the class's attribute is a data descriptor.

Example 1, instance:

class C:
    x = 1
    def __init__(self):
        self.x = 2

C().x

C().x above is 2. It doesn't matter that C.x exists, provided it isn't a data descriptor.
This failure shows up as "shadowed" in the stats

Example 2, class:

class Meta(type):
    x = 1
class C(metaclass=Meta):
    x = 1

C.x

C.x is 2. Meta.x doesn't change that, as it isn't a data descriptor.
This failure shows up as "metaclass attribute" in the stats

Linked PRs

@markshannon
Copy link
Member Author

For STORE_ATTR, the failures show up in various ways, depending on the nature of the class's attribute.

@markshannon markshannon changed the title Unnecessary specialization failures of LOAD_ATTR and STORE_ATTR when attributes are shadowed by the object' class. Unnecessary specialization failures of LOAD_ATTR and STORE_ATTR when attributes are shadowed by the object's class. Aug 15, 2024
@picnixz picnixz added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Aug 16, 2024
@picnixz
Copy link
Member

picnixz commented Aug 16, 2024

Should this one be categorized as a bug or a feature (AFAICT, it's not really a bug per se, it's just an inefficient path being taken)?

@markshannon markshannon added the performance Performance or resource usage label Aug 16, 2024
@markshannon
Copy link
Member Author

I'll just tag it "performance"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.14 bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage
Projects
None yet
Development

No branches or pull requests

2 participants