Does `field_specifier` support non-keyword arguments?

Ouverte
#2,170 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Documentation
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
python
Domaine
documentation

Piste de recherche

Commencez par la spécification de dataclass_transform et sa définition de field_specifiers ; comparez les exemples d’arguments positionnels et nommés dans pyrefly, pyright, mypy et ty. Déterminez si les arguments positionnels doivent être autorisés, puis documentez la décision dans la typing specification et ajoutez un exemple correspondant ou un test de conformité si le projet en possède un.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

topic: documentation

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

Langage dominant
Python
Étoiles
1.8k
Forks
302
Merge moyen
23 h
PR mergées (30 j)
8

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de python/typing

Toutes les issues de python/typing

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.