
Hello, On Mon, 11 Jan 2021 13:44:45 -0800 Larry Hastings <larry@hastings.org> wrote:
The control-flow exclusion is for /module//attribute/ or /class attribute/ annotations:
class C: if random.random() > 0.5: my_attr:int=3 else: my_attr2:float=3.5
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 ======
Your example doesn't define any module attributes or class attributes inside flow control statements, so that code should work fine. (Defining functions/methods inside flow control statements isn't a problem.)
PEP649 criticizes PEP563's approach with big words like "It requires Python implementations to stringize their annotations. This is surprising behavior — unprecedented for a language-level feature." But itself devolves to clauses like:
It seems reasonable to declare that both are at the very least unsupported, and their use results in undefined behavior. It might be worth making a small effort to explicitly prohibit them with compile-time checks.
Isn't the fact that PEP563 doesn't have problems with annotations in conditionals is a sign of PEP563 technical superiority? And its "unprecedented" measure of storing annotations as strings is actually a clever technical feat - it should have stored annotations as AST trees, but such trees would take quite a lot of memory. So, PEP563 smartly went to store those ASTs in a serialized format. So, those strings aren't strings, but serialized ASTs. Overall 2 comments/questions: 1. Was there an attempt to devise how to make PEP649 deal with existing Python language features (like conditionals)? 2. As a general comment, PEP649, by placing arbitrary restrictions on where annotations can appear, tries to dig under the foundations of Python as a dynamic language. Which is absolutely great, it just the PEP should be viewed as such - undermining Python's dynamic nature, as if there's something wrong with it. -- Best regards, Paul mailto:pmiscml@gmail.com