ARF1 <a...@funke.eu> 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 is a "typical" use case which will become very fragile to implement.(E.g. imagine the dataclass with dynamically generated fields, the implementation of which I have neglected for the sake of brevity.) === some_library_typing.py === mytype = str # library author defines some type alias === some_library_module_a.py === from __future__ import annotations import dataclasses from some_library_typing import mytype as mytype_deconflicted mytype = int @dataclasses.dataclass class MyClass: var1: mytype_deconflicted = 'foo' def method1(self, val: mytype) -> mytype: return val + 1 === user_code.py === from __future__ import annotations import dataclasses from some_library_typing import mytype from some_library_module_a import MyClass inst = MyClass('bar') for f in dataclasses.fields(inst): if f.type is mytype: print('mytype found') break else: print('mytype not found') The `if f.type is mytype` comparison obviously won't work any more. But neither will `if f.type == 'mytype'`. The user will have to be aware that the library author had to deconflict the identifier `mytype` to `mytype_deconflicted` to write his code. Of course, the library writer could have written the following to make the code work: === some_library_module_a.py === from __future__ import annotations import dataclasses from some_library_typing import mytype as mytype_deconflicted mytype = int @dataclasses.dataclass class MyClass: var1: mytype = 'foo' def method1(self, val: mytype) return val + 1 That is a phenomenally obscure and counter-intuitive way of writing code! Whichever way one turns this, the current behaviour either seems to require library authors to take extraordinary care with their namespaces when defining dataclasses or forces them to write hard-to-read code or seems to require from users detailed knowledge about the implementation specifics of a library they use. If this behaviour is kept as is, some clear warnings and guidance on how to deal with this in practice should be given in the docs. From what I can see in the 3.10 docs, that is not yet the case. ---------- nosy: +ARF1 versions: +Python 3.9 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue39442> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com