[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

Marco Barisione added the comment: Actually, sorry I realise I can pass `include_extras` to `get_type_hints`. Still, it would be nicer not to have to do that. -- ___ Python tracker

[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

Marco Barisione added the comment: This is particularly annoying if you are using `Annotated` with a dataclass. For instance: ``` from __future__ import annotations import dataclasses from typing import Annotated, get_type_hints @dataclasses.dataclass class C: v: Annotated[int, "foo"]

[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

Inada Naoki added the comment: I think pydantic approach is the best practice. See https://pydantic-docs.helpmanual.io/usage/postponed_annotations/ -- nosy: +methane ___ Python tracker

[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

Dave Tapley added the comment: I don't know if it helps, but I just ran in to this when I followed the advice at (1) because I wanted to type hint a method with the type of the enclosing class. This broke a package I'm working on in parallel (2) because it uses dataclasses.fields

[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

Change by Dan Cecile : -- nosy: +dcecile ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

ARF1 added the comment: Another counter-intuitive behaviour is the different behaviour of dataclasses depending on whether they were defined with the decorator or the make_dataclass factory method: from __future__ import annotations import dataclasses mytype = int @dataclasses.dataclass

[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

ARF1 added the comment: One problem I have with the current behaviour is that users of library code need to know the exact namespace in which a library has defined a dataclass. An example is if a library writer had to deconflict the name of a type he used in a user-facing dataclass. Below

[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

Wojciech Łopata added the comment: I thought of this behaviour as a bug, because PEP 563 mentions breaking "applications depending on arbitrary objects to be directly present in annotations", while it is also breaking users of dataclasses.fields(), that is a part of the standard library.

[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

Eric V. Smith added the comment: > Should `dataclass.Field.type` become a property that evaluates the annotation > at runtime much in the same way that `get_type_hints` works? I think not. But maybe a function that evaluates all of the field types. Or maybe an @dataclass parameter to cause

[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

David Hagen added the comment: Should `dataclass.Field.type` become a property that evaluates the annotation at runtime much in the same way that `get_type_hints` works? -- nosy: +drhagen ___ Python tracker

[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

Eric V. Smith added the comment: Well the type comes from the annotation, so this makes sense to me. If dataclasses were to call get_type_hints() for every field, it would defeat the purpose of PEP 563 (at least for dataclasses). -- ___ Python

[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

Wojciech Łopata added the comment: > Isn't that the entire point of "from __future__ import annotations"? I'm not complaining about Foo.__annotations__ storing strings instead of types. I'm complaining about dataclass.Field.type being a string instead of type. I don't think the former needs

[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

Eric V. Smith added the comment: Isn't that the entire point of "from __future__ import annotations"? Also, please show the traceback when reporting errors so that I can see what's going on. -- ___ Python tracker

[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

Change by Karthikeyan Singaravelan : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

Change by Wojciech Łopata : -- title: from __future__ import annotations breaks dataclasses.Field.type -> from __future__ import annotations makes dataclasses.Field.type a string, not type ___ Python tracker