[Typing-sig] Re: Proposal for @typing.override

Well, ‘@abstract’ requires a meta class, so there’s some precedent. I won’t insist however. On Thu, Aug 18, 2022 at 19:31 Jelle Zijlstra wrote:

El jue, 18 ago 2022 a las 19:15, Steven Troxler () escribió:

...

Hi all -

Thanks for all the helpful suggestions on this proposal! One question has come up that I wanted to bring back to the full typing-sig list:

We are thinking about what kind of runtime logic `@typing.override` should have.

Jelle suggested that it should set an `__override__` attribute that would allow introspection. This seems like an obviously good idea and we've added it to our reference implementation [1][2] as well as the draft proposal.

Several folks also suggested that we consider adapting the existing runtime enforcement in `@overrides.overrides`.

This could be very cool, because override safety for renames makes sense even for folks who don't use static typing, plus it may help folks who run unit test more often than type checking get feedback faster.

The main downside is that it would add a bit of import-time overhead; my estimate is something like 120 microseconds per override [3]. This is relatively minor, although for a million line codebase we think it might introduce something like 0.75 seconds of fixed cost import time. It may be possible to reduce this significantly by moving the implementation to C.

From the Pyre team's side, I'm not sure we would want runtime enforcement on our largest codebases since the type checker can catch errors just as well, but we already have @pyre_extensions.override so this is not a major concern.

Do y'all have opinions on this? For now, I've moved the idea into the "Open Issues" section of the draft proposal [4]

I would oppose runtime validation because I see no clean way to implement it. The @override decorator runs during the execution of the class namespace, which is before the class actually exists, so it's not obvious how validation could work. The overrides library does it by introspecting the bytecode of the calling frame to figure out the class's bases ( https://github.com/mkorpela/overrides/blob/9d0356b5476489bb4fbe7179e30c3d47f...), and that's not something I'd want to see in typing.py. Bytecode introspection is only going to get more fragile in the future as the faster CPython team tinkers with the interpreter.

There are alternative approaches, but I don't like them either. A metaclass (or __init_subclass__ override) could run code after the class is created, introspect whether any class member has the __override__ attribute, and check that it is indeed an override. But I wouldn't want to force every user of the feature to add a special metaclass or __init_subclass__ to their class to use @overrides. We could also implement this behavior in the core language in the default metaclass (type), but then we'd slow down the creation of *all* classes, and I'm not sure the feature is sufficiently compelling to justify a change in the language core.

...

---

[1] Add `__override__` attribute in `pyre_extensions`

https://github.com/facebook/pyre-check/blob/main/pyre_extensions/__init__.py...

[2] Unit tests for `__override__` behavior

https://github.com/facebook/pyre-check/blob/main/pyre_extensions/tests/basic...

[3] Simple perf estimate for `@overrides.overrides`

https://github.com/stroxler/python_open_source_examples/tree/main/timing_ove...

[4] Draft PEP for @typing.override

https://docs.google.com/document/d/1dBkHKaOCqttnqzPo7kw1dzvbuFzNoOdx7OPyfbJH. .. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com

_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: guido@python.org

-- --Guido (mobile)