> On Sep 13, 2017, at 2:56 PM, Jim J. Jewett <jimjjew...@gmail.com> wrote: > > I am generally supportive of leaving the type annotations unprocessed > by default, but there are use cases where they should be processed > (and even cases where doing it at the right time matters, because of a > side effect).
What is the "right time" you're speaking of? > (1) The PEP suggests opting out with @typing.no_type_hints ... The > closest I could find was @typing.no_type_check, which has to be called > on each object. This was a typo on my part. Yes, no_type_check is what I meant. > It should be possible to opt out for an entire module, and it should > be possible to do so *without* first importing typing. > > Telling type checkers to ignore scopes (including modules) with a > > # typing.no_type_hints > > comment would be sufficient for me. This is already possible. PEP 484 specifies that "A # type: ignore comment on a line by itself is equivalent to adding an inline # type: ignore to each line until the end of the current indented block. At top indentation level this has effect of disabling type checking until the end of file." > (2) Getting the annotations processed (preferably at the currently > correct time) should also be possible on a module-wide basis, and > should also not require importing the entire typing apparatus. Again, what is the "correct time" you're speaking of? > It would be a bit messy (like the old coding cookie), but recognizing > a module-wide > > # typing.no_type_hints > > comment and then falling back to the current behavior would be enough for me. Do you know of any other per-module feature toggle of this kind? __future__ imports are not feature toggles, they are timed deprecations. Finally, the non-typing use cases that you're worried about, what are they? From the research I've done, none of the actual use cases in existence would be rendered impossible by postponed evaluation. So far the concerns about side effects and local scope in annotations aren't supported by any strong evidence that this change would be disruptive. Don't get me wrong, I'm not being dismissive. I just don't think it's reasonable to get blocked on potential and obscure use cases that no real world code actually employs. - Ł
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
