<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-09-13 13:01 GMT-07:00 Jim J. Jewett <span dir="ltr"><<a href="mailto:jimjjewett@gmail.com" target="_blank">jimjjewett@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Sep 13, 2017 at 3:12 PM, Lukasz Langa <<a href="mailto:lukasz@langa.pl">lukasz@langa.pl</a>> wrote:<br>
> On Sep 13, 2017, at 2:56 PM, Jim J. Jewett <<a href="mailto:jimjjewett@gmail.com">jimjjewett@gmail.com</a>> wrote:<br>
<br>
>> I am generally supportive of leaving the type annotations<br>
>> unprocessed by default, but there are use cases where<br>
>> they should be processed (and even cases where doing it<br>
>> at the right time matters, because of a side effect).<br>
<br>
> What is the "right time" you're speaking of?<br>
<br>
</span>The "right time" is whenever they are currently evaluated.<br>
(Definition time, I think, but won't swear.)<br>
<br>
For example, the "annotation" might really be a call to a logger,<br>
showing the current environment, including names that will be rebound<br>
before the module finishes loading.<br>
<br>
I'm perfectly willing to agree that even needing this much control<br>
over timing is a code smell, but it is currently possible, and I would<br>
rather it not become impossible.<br></blockquote><div><br></div><div>Is this just a theoretical concern? Unless there is significant real-world code doing this sort of thing, I don't see much of a problem in deprecating such code using the normal __future__-based deprecation cycle.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
At a minimum, it seems like "just run this typing function that you<br>
should already be using" should either save the right context, or the<br>
PEP should state explicitly that this functionality is being<br>
withdrawn.  (And go ahead and suggest a workaround, such as running<br>
the code before the method definition, or as a decorator.)<br>
<span class=""><br>
<br>
>> (1)  The PEP suggests opting out with @typing.no_type_hints ...<br>
<br>
</span><span class="">> This is already possible. PEP 484 specifies that<br>
<br>
> "A # type: ignore comment on a line by itself is equivalent to adding an<br>
> inline # type: ignore to each line until the end of the current indented<br>
> block. At top indentation level this has effect of disabling type checking<br>
> until the end of file."<br>
<br>
</span>Great!  Please mention this as well as (or perhaps instead of)<br>
typing.no_type_check.<br>
<span class=""><br>
<br>
>> It would be a bit messy (like the old coding cookie),<br>
>> but recognizing a module-wide<br>
<br>
>> # typing.no_type_hints<br>
<br>
>> comment and then falling back to the current behavior<br>
>> would be enough for me.<br>
<br>
> Do you know of any other per-module feature toggle of this kind?<br>
<br>
</span>No, thus the comment about it being messy.  But it does offer one way<br>
to ensure that annotations are evaluated within the proper<br>
environment, even without having to save those environments.<br>
<div class="HOEnZb"><div class="h5"><br>
-jJ<br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</div></div></blockquote></div><br></div></div>