Does `field_specifier` support non-keyword arguments?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- python
- Domain
- documentation
Research direction
Start with the dataclass_transform specification and its field_specifiers definition; compare the positional and keyword examples across pyrefly, pyright, mypy, and ty. Determine whether positional arguments should be permitted, then document the decision in the typing specification and add a corresponding example or conformance test if the project has one.
Written by the indexing model from the issue text.
Description
I was reading through the specification of dataclass_transform and it doesn't really specify what field_specifiers looks like. It mostly just says:
field_specifiers (tuple[Callable[..., Any], ...]) – Specifies a static list of supported classes or functions that describe fields, similar to dataclasses.field(). Defaults to ().
But dataclasses.field takes keyword-only arguments, which leaves it a bit ambiguous about whether positional arguments are ok. For example:
from typing import dataclass_transform, Any
def custom_field(default: object, *, init: bool = True) -> Any: ...
@dataclass_transform(field_specifiers=(custom_field,))
def build(x): ...
@build
class A:
x: int = custom_field(default=0)
@build
class B:
x: int = custom_field(0)
A()
B()
pyrefly, pyright, and mypy all flag B() as an error while ty accepts it without complaint.
My (uninformed) take is that this should be allowed -- custom_field(default=0) and custom_field(0) have the same runtime effect, so it feels like they should have the same type-checking effect too. This also matches how pydantic and attrs works (e.g. you can do pydantic.Field(1) and attr.ib(0)) -- today I suspect the type-checkers are special-casing this to make pydantic and attrs (since I've definitely used both without running into static type-checking errors about missing default values before).
- Dominant language
- Python
- Stars
- 1.8k
- Forks
- 302
- Avg merge
- 23h
- Merged PRs (30d)
- 8
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from python/typing
-
topic: typing spec
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
topic: typing spec
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
topic: documentation
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
topic: documentation
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
topic: conformance tests topic: typing spec
Difficulty 3/5 1-2 days Newbie friendliness 72/100
Similar issues
-
Add: hunch Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
AbdelStark/awesome-typesafe#104 ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
DiamondLightSource/dodal#2211 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
openml/openml-python#1749 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
sipyourdrink-ltd/bernstein#6191 ·