
Hello, On Wed, 13 Jan 2021 05:04:36 -0000 "Jim J. Jewett" <jimjjewett@gmail.com> wrote:
Paul Sokolovsky wrote:
Ok, let's take "module attribute" as an example. Why do you think there's anything wrong with this code: ====== import config from .types import * if config.SUPPORT_BIGINT: var: bigint = 1 else: var: int64 = 1
"Wrong" is too strong, but it would be better as
mybigint = bigint if config.SUPPORT_BIGINT else int64 ... var:mybigint = 1
What's the explanation of why the above is better? It seems following is ok with PEP649: if config.LAYOUT_INT: @dataclass class MyData: val: int else: @dataclass class MyData: val: float So, how to explain to people that using the normal "if" is ok when defining classes/dataclasses, but suddenly not normal when defining just variables, and people should switch to the "if" expression?
so asking people to rewrite it that way over the course of a major release is probably an acceptable price.
But why haste to ask people to rewrite their code? Why not start with saying that PEP649 is not backward compatible, and ask it to explain why it has pretty arbitrary limitations and discrepancies like above? Then ask it how it can achieve backward compatibility? And that way is obvious - the smart code objects which PEP649 creates, they should store annotations just like PEP563 does, in a serialized form. Then those smart code objects would deserialize and evaluate them. They may even cache the end result. But wait, PEP563 already has all that! It provides public API to get annotations, typing.get_type_hints(), which already does all the deserialization (maybe it doesn't do caching - *yet*), and effectively treats __annotations__ as implementation detail. Because clearly, the format of information stored there already depends on a particular CPython version, and if you believe a thread running in parallel, going to change going forward. Seen like that, PEP649 is just a quest for making __annotations__ be the "public API", instead of the already defined public API, and which __annotations__ already can't be, as its format already varies widely (and likely will keep varying going forward). And while questing for that elusive goal, it even adds arbitrary restrictions for usage of annotations which never were there before, truly breaking backward compatibility and some annotation usages. -- Best regards, Paul mailto:pmiscml@gmail.com