[Typing-sig] Re: Supporting dataclass-like semantics

I applaud any efforts to standardize more typing features and reduce the need for plugins. Currently, I am using the `if TYPE_CHECKING` hack mentioned above with pydantic to avoid having to install its mypy plugin. As a data-point, I believe this specification in it's current form doesn't allow capturing the semantics of Django ORM's Model objects accurately. Therefore, I think it would make sense to remove Django from the list of targeted use-cases. Django Models don't support declaring fields using type-annotations only: class MyModel(Model): a: int # This is not a field b = IntegerField() # This is a field c = ForeignKey(OtherModel) # This is also a field Additionally, it would not entirely help with the __init__ method, as there is Django-specific logic which adds extra fields. Here are some examples of this logic: - There is an automatically-added `id` and `pk` field, however the `id` field is not added when you have explicitly added a field designated as the `primary_key`. - ForeignKeys add a field with the field name appended with `_id`, the type being the type of the primary key on the referenced model. In this example, the __init__ method would roughly look like: def __init__(self, id: Optional[int], b: int, c: OtherModel, *, pk: Optional[int] = None, c_id: Optional[int] = None) -> None: ... Whereas the spec would (I assume) only allow generating a method like this: def __init__(self, a: int, b: int, c: OtherModel) -> None: ... This would still be somewhat useful as an approximation, as users could always add type ignores silencing the errors about additional fields. I could see supporting this extra `c_id` field being possible if Python had certain rather complicated features from TypeScript: mapped types and conditional types ( https://www.typescriptlang.org/docs/handbook/2/mapped-types.html#further-exp...) and template literal types ( https://www.typescriptlang.org/docs/handbook/2/template-literal-types.html). By the way, there is also a `Model.objects.create` method, which has identical parameters to the Model's __init__ method. It would be nice if there was some way of specifying this. That method however, lives on Model.objects, which is an instance of `Manager`. I don't know if it requires some kind of associated types. Best regards, Seth Yastrov On Sun, Apr 25, 2021 at 8:22 PM Guido van Rossum wrote:

I agree we don't need to over-generalize, I just worry about applicability to lesser-known libraries that we haven't heard of yet. So it would be a good idea to have a plan *if* that need arises.

In any case I assume this is just a stopgap measure until we have true portable type system extensions...

On Sat, Apr 24, 2021 at 11:10 PM Eric Traut wrote:

...

Guido, thanks for the feedback. I've updated the spec to incorporate your suggestions.

Yes, I'm recommending that we fix the names of the various allowable keyword parameters. The popular libraries use these parameter names, and I don't see a need to provide additional flexibility here. Of course, we could add more configurability if there's a need, but I'd prefer to keep it simple.

-Eric

-- Eric Traut Contributor to Pyright & Pylance Microsoft Corp. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: guido@python.org

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c... _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: syastrov@gmail.com