
On Nov 29, 2021, at 15:57, Larry Hastings <larry@hastings.org> wrote:
On 11/29/21 2:56 PM, Barry Warsaw wrote:
PEP 563 and 649 have visible effects that even within that domain can have important side effects. For example, PEP 563’s loss of local scope, which even “de-stringify-ing” can’t recover. This is what we need help with. Well, sure. If PEP 563 and 649 didn't have visible effects, there'd be no point in doing them. That said, I suggest 649 does a lovely job of avoiding undesirable side-effects.
Sure, 649 has observable side effects. For example, you can detect whether or not 649 is active by rebinding a name after it's used in an annotation but before examining that annotation at runtime. This seems harmless--unlikely to happen in production code, and easily remedied if someone did trip over it.
PEP 563 also has visible side effects, but the real implication of them wasn’t well understood at the time the PEP was approved. Or maybe it was and we underestimated the impact on certain important users and use cases. I’m particularly wary about getting into that same (um) pickle again.
A more credible side effect: if you use an undefined name in an annotation, you won't notice at compile-time. Now, this is actually 649's major feature! But there are also scenarios where this feature could cover up a bug, like if you misspell a name--you won't notice until you examine the annotation at runtime (or, more likely, until you run your static analyzer). 563 has this same behavior--and it wasn't enough to prevent 563 being accepted. So I assume this wouldn't be enough to prevent accepting 649 either.
How common is it for code to examine annotations at run time, outside of specialized libraries that have to be more defensive anyway (especially given they already have to be defensive in light of 563)?
649 has effects on memory usage and performance, but honestly I'm not worried about these. I don't think the memory usage and performance of the prototype were particularly bad. Anyway, as I've said many times: we should figure out the semantics we want first, and then we can worry about optimization. The Python core dev community has no end of smart people who love optimizing things--I'm sure if 649 was accepted and merged, the optimizations would start rolling in.
I agree about that priority (semantics first, optimization later), as long as those semantics don’t make such future optimizations impossible, or severely degrade important performance constraints such as import times.
Then of course there are also things 649 simply doesn't do, e.g. resolve the "if TYPE_CHECKING" situation. But it's not appropriate to call that a "side effect" per se.
Although, it would be nice to have a comprehensive solution to this and other situations too, even if they happen outside of PEP 563/649 discussion…
And that's my list. If anybody knows of other visible side effects from 649, naturally you should contact the SC. And/or me, if you think we could change 649 to mitigate it without losing its major features.
That list is exactly what I'm (we’re?) looking for. -Barry