what does pep681 define as the behavior for missing annotations

[zzzeek]

If I make a dataclass like this, it fails with TypeError: 'y' is a field but has no type annotation:

import dataclasses


@dataclasses.dataclass
class MyClass:
    id: int
    x: int = dataclasses.field()
    y = dataclasses.field()

What is pep-681's behavior for custom, dataclass-like systems which may (depending on how this discussion goes) ignore such fields from a dataclass perspective, rather than raise TypeError? right now, pyright seems to do the same, that is, it ignores fields on the class that don't have annotations, does not consider them as part of the init constructor, but does not report them as typing errors.

that is, this passes, given a @dataclass_transform class with mapped_column() as a field descriptor:

class Address(Base):

    id: Mapped[int] = mapped_column(init=False)
    user_id = mapped_column()
    email_address: str

above, "user_id" is not part of the constructor for Address but no error is reported.

[zzzeek]

noting that my preference is that we'd be able to ignore them, which allows for some additional configurational options and potentially better support for legacy code. but if it should be a TypeError, so be it.

[debonte]

I had to do some historical digging to understand this behavior. The dataclass docs claim that, "A field is defined as a class variable that has a type annotation." However, the error in the "field() with no annotation" scenario was added under the assumption that the user intended the variable to be a field and accidentally left off the annotation or didn't understand that annotations were required. The discussion about this started in https://bugs.python.org/issue32428 and then moved to https://bugs.python.org/issue32505.

Since this case is not explicitly called out in PEP 681, this would currently fall in the bucket of "except where stated otherwise in this PEP, classes impacted by dataclass_transform...are assumed to behave like stdlib dataclass."

However, if we feel that other libraries would also benefit from not erroring in this scenario, we could consider never erroring in this case for dataclass_transform or adding a dataclass_transform parameter to optionally turn off this behavior.

[erictraut]

Pyright doesn't currently flag this as an error because I wasn't aware that an unannotated class variable initialized to a field instance generates a runtime exception. This doesn't appear to be documented in PEP 557 or the official dataclass documentation.

My preference here is that if dataclass treats this as an error, dataclass_transform should as well, and a type checker should accordingly generate an error to inform the user that an exception will be raised at runtime.

[zzzeek]

that's fine, as always, it would be great if this could be called out in either of those peps. that way type checkers that don't use that behavior can be called out as having a bug that needs to be fixed.

[debonte]

I think the dataclass documentation would be the right place to call this out. PEP 557 can't be modified at this point, and PEP 681 wouldn't be the right place for this IMO.

But you could already file a bug on a type checker and point them at https://bugs.python.org/issue32505 as proof that this is the expected behavior. Eric already filed a Pyright issue btw.