[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Change by Eric V. Smith : -- priority: release blocker -> resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.8 ___ Python tracker

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

miss-islington added the comment: New changeset c73268aad7645a146b3e0e088c198a1fb74d57ff by Miss Islington (bot) in branch '3.7': bpo-33453: Handle string type annotations in dataclasses. (GH-6768)

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Change by miss-islington : -- pull_requests: +6562 ___ Python tracker ___

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Eric V. Smith added the comment: New changeset 2a7bacbd913cf2bf568b3c0f85a758946d3cf4e9 by Eric V. Smith in branch 'master': bpo-33453: Handle string type annotations in dataclasses. (GH-6768)

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Change by Gregory P. Smith : -- nosy: +gregory.p.smith ___ Python tracker ___ ___

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Eric V. Smith added the comment: Followup from our meeting at the sprints: we're going to go with inspecting the type annotation string and use heuristics to determine if the type is a ClassVar or InitVar. I'll follow up with more specifics on the approach. This will

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Eric V. Smith added the comment: There have been comments on the PR, but I'd like to focus the higher level issue back here. Specifically, see my comment https://github.com/python/cpython/pull/6768#discussion_r187813919 To summarize: I still think string inspections are

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Change by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker ___ ___

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Eric V. Smith added the comment: At this stage in the release cycle, if you really feel strongly about this, you should take it up with Guido directly. -- assignee: -> eric.smith ___ Python tracker

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Change by Eric V. Smith : -- keywords: +patch, patch pull_requests: +6455, 6456 stage: -> patch review ___ Python tracker ___

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Change by Eric V. Smith : -- keywords: +patch pull_requests: +6456 stage: -> patch review ___ Python tracker ___

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

INADA Naoki added the comment: > > I think we've learned lesson that we shouldn't use typing in modules other than typing... > This is a blanket statement that as hurtful as it is factually incorrect. Let me address the latter. > 1. Dataclasses are entirely dependent

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Rick Teachey added the comment: Lending my voice to the suggestion of limiting the class attribute check to `typing.ClassVar` and `ClassVar`. It can always be expanded later if it is needed. -- ___ Python tracker

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Łukasz Langa added the comment: > I think we've learned lesson that we shouldn't use typing in modules other > than typing... This is a blanket statement that as hurtful as it is factually incorrect. Let me address the latter. 1. Dataclasses are entirely dependent on

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

INADA Naoki added the comment: > We can't break the API at this point in the release cycle. We hadn't release RC, and we hadn't documented dataclass module yet. How about making "dataclass" module as porvisional state? I think we've learned lesson that we shouldn't use

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Eric V. Smith added the comment: We can't break the API at this point in the release cycle. But I am open to what string prefixes we should allow. -- ___ Python tracker

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

INADA Naoki added the comment: "t.ClassVar" looks ugly... How about dropping ClassVar support of dataclass module for 3.7? -- nosy: +inada.naoki ___ Python tracker

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Eric V. Smith added the comment: The more I think about this, the more I think Łukasz is correct that just checking for strings starting with "ClassVar", "typing.ClassVar", or "t.ClassVar" is the correct thing to do. This is the change he made in

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Rick Teachey added the comment: > Is there any scenario where the following code would be useful... Perhaps if someone, in search of a speedup, were sort of rolling their own lighter-weight equivalent to the typing module (in order to avoid importing the full typing

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Eric V. Smith added the comment: I see that https://github.com/python/typing/issues/508 is also referenced in https://github.com/python-attrs/attrs/issues/361, where it contributed to attrs using string inspection. -- ___

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Eric V. Smith added the comment: See also [2]_ for a brief discussion of forward references, which makes get_type_hints() undesirable in this case. > This is why attrs went with the fast way which covers most (but not all) > bases in this case. If the annotation is a

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Ned Deily added the comment: > Ned, this is after the last beta but as far as I understand, we're still > fine committing fixes that maintain ABI until RC1, right? Yes -- ___ Python tracker

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Change by Łukasz Langa : -- Removed message: https://bugs.python.org/msg316344 ___ Python tracker ___

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Łukasz Langa added the comment: Well, this is a rather big deal and I'd like to see it solved for 3.7.0. Ned, this is after the last beta but as far as I understand, we're still fine committing fixes that maintain ABI until RC1, right? Note that this isn't specific to the

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Łukasz Langa added the comment: Well, this is a rather big deal and I'd like to see it solved for 3.7.0. Ned, this is after the last beta but as far as I understand, we're still Note that this isn't specific to the `annotations` future import. If a user actually writes:

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Eric V. Smith added the comment: This is a known issue, but it wasn't being tracked here. So, thanks for opening the issue. https://github.com/ericvsmith/dataclasses/issues/92#issuecomment-382473127 Not to put Łukasz on the spot (he's sitting behind me even as we speak),