Cannot declare class with attributes about cinder HOT 10 CLOSED

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.

from cinder.

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.

from cinder.

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

from cinder.

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.

from cinder.

from cinder.

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/

from cinder.

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/

from cinder.

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.

from cinder.

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."

from cinder.

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

from cinder.