facebookincubator / cinder

Cinder is Meta's internal performance-oriented production version of CPython.

Home Page:https://trycinder.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Cannot declare class with attributes

LuKuangChen opened this issue · comments

commented

What version of Static Python are you using?

9965302
2021-07-13

What program did you run?

class C:
    x: int = 3

What happened?

ValueError: 'x' in __slots__ conflicts with class variable

What should have happened?

We expected the program to terminate without errors.

The error confuses us because it mentions __slots__. As far as we can tell from the python doc and a stackoverflow, __slots__ is used to optimize access to instance attributes. And this optimization has to be enabled in a manual and low-level manner. From this perspective, class attributes should have little to do with slots, unless a class attribute is shadowed by an instance attribute.

We found a similar test in cinder/test_static.py

    def test_class_level_final_reinitialized_directly(self):
        codestr = """
        from typing import Final

        class C:
            x: Final[int] = 3

        C.x = 4
        """
        # Note - this will raise even without the Final, we don't allow assignments to slots
        with self.assertRaisesRegex(
            TypedSyntaxError,
            type_mismatch("Literal[4]", "Exact[types.MemberDescriptorType]"),
        ):
            self.compile(codestr, StaticCodeGenerator, modname="foo")

We wonder

  • How to read the line x: Final[int] = 3? Is this an initialization, an assignment, or both?
  • Does Static Python have class attributes? Or are you only supposed to declare the fields that instances will have?

This looks like it should be allowed and seems like a valid bug, it looks like when we added final support our support for non-final class level declarations was broken. We're doing some tracking on whether or not the final attributes are assigned which might be too clever. If the attribute is not final, and assigned, then this should just represent a class level attribute.

To clarify for anyone not familiar with Python typing specs, I was using "PEP 484" as shorthand for the set of PEPs that specify Python typing; the actual PEP that introduced variable/attribute annotations and ClassVar is PEP 526: https://www.python.org/dev/peps/pep-0526/

Thinking about it more we could actually support the "instance variable with default" pattern as well. We'd just need to transform it into something like:

class C:
x: int = 3
slots = ('x', )
slot_defaults = ('x': x)
# or
slots_with_defaults = ('x', )

Such that we suppress the "ValueError: 'x' in slots conflicts with class variable" error and when the instance doesn't define it you get the default value.

With this specific "x: Final[int] = 3" case though, it seems like that's implicitly a ClassVar if it's assigned and an instance var without one per PEP 591? https://www.python.org/dev/peps/pep-0591/

Thinking about it more we could actually support the "instance variable with default" pattern as well.

We could, but I wonder if this would mostly lead to people trying to make class attributes without using ClassVar and it seeming to work but then accessing the attribute on the class won't give them what they expect. It might be better to give a clear error outlining the options instead of guessing intent on x: int = 3?

With this specific "x: Final[int] = 3" case though, it seems like that's implicitly a ClassVar if it's assigned and an instance var without one per PEP 591? https://www.python.org/dev/peps/pep-0591/

Ah good call, I didn't realize Final was special in that way. It seems a little unfortunate to me to give up the consistency of "class attrs always use ClassVar" in this specific case, but I understand the reasoning of the PEP: if it's Final you can't reassign it so if it's initialized on the class and final, it must be a class attribute.

I think if they do make a ClassVar without using it they'll still get what they'd expect. A pure Python implementation of this would look like:

class _slot_with_default:
    def __init__(self, default, orig_slot):
        self.default = default
        self.orig_slot = orig_slot
    def __get__(self, inst, ctx):
        if inst is None:
            return self.default
        try:
            return self.orig_slot.__get__(inst, ctx)
        except AttributeError:
            return self.default
    def __set__(self, inst, value):
        self.orig_slot.__set__(inst, value) 

class C:
    __slots__ = ('x',)

C.x = _slot_with_default(42, C.x)

And so C.x would return the default, C().x would return the default, and you could still do some_c.x = 100 and get that value back out.

One downside of _slot_with_default is that it puts a type constraint on instances. If a class declares x:int = 3 then its instances can't declare x:str = "X" because they inherit a typed slot.

This could be a problem if people are used to thinking of class vars and object vars as living in two different namespaces. E.g. "My instance can use any field name. I don't need to avoid names that happen to be class vars."

This could be a problem if people are used to thinking of class vars and object vars as living in two different namespaces

Python developers won't expect this, in Python they have always shared the same namespace.

We now report an error "Class attribute requires ClassVar[...] annotation: x" but support for the default is under way!

This is now supported; we create a slot with a default value at the class level.