[issue37948] get_type_hints fails if there are un-annotated fields in a dataclass
New submission from Arne Recknagel :
When declaring a dataclass with make_dataclass, it is valid to omit type
information for fields. __annotations__ understands it and just adds
typing.Any, but typing.get_type_hints fails with a cryptic error message:
>>> import dataclasses
>>> import typing
>>> A = dataclasses.make_dataclass('A', ['a_var'])
>>> A.__annotations__
{'a_var': 'typing.Any'}
>>> typing.get_type_hints(A)
Traceback (most recent call last):
File "", line 1, in
File "/user/venvs/python_3.7/lib/python3.7/typing.py", line 973, in
get_type_hints
value = _eval_type(value, base_globals, localns)
File "/user/venvs/python_3.7/lib/python3.7/typing.py", line 260, in _eval_type
return t._evaluate(globalns, localns)
File "/user/venvs/python_3.7/lib/python3.7/typing.py", line 464, in _evaluate
eval(self.__forward_code__, globalns, localns),
File "", line 1, in
NameError: name 'typing' is not defined
Adding typing.Any explicitly is an obvious workaround:
>>> B = dataclasses.make_dataclass('B', [('a_var', typing.Any)])
>>> typing.get_type_hints(B)
{'a_var': typing.Any}
There is already a bug filed regarding datalcasses and get_type_hints which
might be related: https://bugs.python.org/issue34776
--
messages: 350488
nosy: arne, eric.smith
priority: normal
severity: normal
status: open
title: get_type_hints fails if there are un-annotated fields in a dataclass
type: behavior
versions: Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue37948>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38277] Allowing conditions with assignment expressions in comprehensions without parantheses
New submission from Arne Recknagel : All code is run on python build from the current 3.8 branch. The following doesn't work: >>> [x for x in 'foo' if y := True] File "", line 1 [x for x in 'foo' if y := True] ^ SyntaxError: invalid syntax While this does: >>> [x for x in 'foo' if (y := True)] ['f', 'o', 'o'] Since assignment expressions work without parentheses in normal if-clauses and there being no mention on it explicitly being disallowed, this seems to either be a bug or an oversight in the documentation (with my own opinion, for what it's worth, being that it's a bug). -- messages: 353203 nosy: arne, emilyemorehouse priority: normal severity: normal status: open title: Allowing conditions with assignment expressions in comprehensions without parantheses versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38277> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38277] Allowing conditions with assignment expressions in comprehensions without parantheses
Arne Recknagel added the comment: Nothing in particular, only that I expected it to follow the same rules as regular if-blocks. It would be nice to have, since it'd be one less thing to keep in mind. > There are some tricky issues in this particular bit of syntax [...] It looks like there are good reasons to keep it this way or wait with potentially misleading docu updates. Then this issue can just serve to point out that it might be something to fix in either way, since I can see people stumbling over it. -- ___ Python tracker <https://bugs.python.org/issue38277> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38277] Allowing conditions with assignment expressions in comprehensions without parantheses
Arne Recknagel added the comment: I'll keep shouting from the sidelines, if it's ok. Is the following behavior still desired >>> [z := x for x in 'foo'] # valid over forcing parentheses here as well? >>> [(z := x) for x in 'foo'] # also valid, but redundant parentheses The section on when to add parentheses in comprehensions would be a lot simpler if the answer was 'always', with an asterisk saying that the restriction might be lifted for some cases if there is a demand and a good-enough implementation. -- ___ Python tracker <https://bugs.python.org/issue38277> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38277] Allowing conditions with assignment expressions in comprehensions without parantheses
Arne Recknagel added the comment: Alright, fair enough -- ___ Python tracker <https://bugs.python.org/issue38277> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34632] Port importlib_metadata to Python 3.8
Arne Recknagel added the comment: Is there a reason the object returned by importlib.metadata.metadata is an EmailMessage and not a dict? If it quacks like a duck it should be a duck, no? -- nosy: +arne ___ Python tracker <https://bugs.python.org/issue34632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34632] Port importlib_metadata to Python 3.8
Arne Recknagel added the comment: I just learned that metadata is stored as an email, and changing the format was rejected in PEP 426. Be that as it may, if it isn't too much of an issue it might still be something that should be hidden from users of the module. Noone wants to know that this particular duck is actually powered by fins under the surface, right? -- ___ Python tracker <https://bugs.python.org/issue34632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
