Does converter also support default argument in field specifiers of dataclass_transform?

[PragmaTwice]

In the typing spec (https://typing.python.org/en/latest/spec/dataclasses.html#field-specifier-parameters), when describing the field specifiers that can appear in dataclass_transform, the spec provides the following code example:

# Library code (within type stub or inline)
# In this library, passing a resolver means that init must be False,
# and the overload with Literal[False] enforces that.
@overload
def model_field(
        *,
        default: Optional[Any] = ...,
        resolver: Callable[[], Any],
        init: Literal[False] = False,
    ) -> Any: ...

@overload
def model_field(
        *,
        default: Optional[Any] = ...,
        resolver: None = None,
        init: bool = True,
    ) -> Any: ...

@typing.dataclass_transform(
    kw_only_default=True,
    field_specifiers=(model_field, ))
def create_model(
    *,
    init: bool = True,
) -> Callable[[Type[_T]], Type[_T]]: ...

# Code that imports this library:
@create_model(init=False)
class CustomerModel:
    id: int = model_field(resolver=lambda : 0)
    name: str

In this example, parameters like init can have default arguments, so users don't need to explicitly provide these arguments when calling. pyright/ty respects these default arguments, but mypy does not.

However, for converter, the situation is different. Pyright does not respect the default argument for converter. Other type checkers seem to have not yet implemented support for converter.

I opened an issue in Pyright (microsoft/pyright#11291), but it was closed by @erictraut , who claimed

dataclass_transform mechanism (described in the Python typing spec) does not support field descriptors with default arguments

Since he is one of the authors of the dataclass_transform proposal, and the spec is unclear on this matter, I’m also left confused.

---

The below is my context around this question.

My current requirement is: for certain specific kinds of fields, the parameters in __init__ must be of a different type. For example:

class AddOp(Operation):
  result: Result
  lhs: Operand
  rhs: Operand

# auto-generated constructor and accessors
AddOp.__init__(result: Type, lhs: Operand, rhs: Operand) # result should be typed `Type` in constructor
AddOp(..).result: Result # but the accessor should be typed `Result`
AddOp(..).rhs: Operand
AddOp(..).lhs: Operand

In this case, for fields of type Result, the user must provide a specific converter (e.g., def convert(result: Type) -> Result), while for fields of other types the user must not be allowed to provide one.

If there were a type-dependent way to specify a field specifier, that would be ideal. We could automatically derive what specifier a field needs from its field type. But that clearly requires a new proposal and might not be accepted. So the alternative would be to provide a special field specifier and give it a default converter, but based on pyright maintainer's explanation that also isn’t allowed.

[pratikrath126]

According to the Python typing specification and statements from the dataclass_transform proposal authors, field specifiers like converter in dataclass_transform do not support default arguments. The mechanism is designed to not allow default arguments for field descriptors to avoid ambiguity.

As mentioned in the Pyright issue, this is by design. Type checkers should not expect or support default arguments for converter in this context.

[PragmaTwice]

This seems to be a bot account (no any activity in the typing repo) and LLM-generated answer. So I'll ignore this.

[rolfmorel]

Just to echo: it would be much appreciated if the spec could be updated to be clear on that default arguments on (custom) fie