Hi, now that the alias resolution is fixed for field transformations (#1479, @veeceey), I stumbled over another (potential!?) issue and wanted to ask if this behavior is intended or possibly due to a wrong type annotation:
from attrs import define, field, fields
@define
class Class:
attr1: str = field(alias="attribute1")
attr2: str = field()
reveal_type(fields(Class).attr1.alias)
reveal_type(fields(Class).attr2.alias)
dbg.py:12: note: Revealed type is "str | None"
dbg.py:13: note: Revealed type is "str | None"
Of course, the input type str | None of alias for Attribute makes sense for the constructor, as define here:
)
But for the created Attribute instance, the type of the alias attribute is guaranteed to be str since it defaults to name if not set explicitly. However, as the code snippet above shows, resulting type is still an str | None. This causes inconvenience on the caller's side because it now requires workarounds like assert attr.alias is not None to satisfy the type checkers.
Is there any deeper reason for this?
Hi, now that the
aliasresolution is fixed for field transformations (#1479, @veeceey), I stumbled over another (potential!?) issue and wanted to ask if this behavior is intended or possibly due to a wrong type annotation:Of course, the input type
str | NoneofaliasforAttributemakes sense for the constructor, as define here:attrs/src/attr/__init__.pyi
Line 139 in f0e420b
But for the created
Attributeinstance, the type of thealiasattribute is guaranteed to bestrsince it defaults tonameif not set explicitly. However, as the code snippet above shows, resulting type is still anstr | None. This causes inconvenience on the caller's side because it now requires workarounds likeassert attr.alias is not Noneto satisfy the type checkers.Is there any deeper reason for this?