<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 22 December 2014 at 14:05, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""></span>I would really like to wait and see how this plays out -- the proposal I'm working on is careful not to have any effect at runtime (as long as the typing.py module can be imported and as long as the annotation expressions don't raise exceptions), and use of a static checker is entirely optional and voluntary.<br></div></div></div></blockquote><div><br></div><div>Agreed - I see this as a good, incremental evolution from the increased formality and flexibility in the type system that was introduced with ABCs, and I think that's been successful in letting folks largely not need to worry about them unless they actually need to deal with the problems they solve (like figuring out whether a container is a Sequence or Mapping).<br><br></div><div>Ideally we'll get the same result here - folks that have problems where type annotations can help will benefit, while those that don't need them won't need to worry about them.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Perhaps the PEP should define some way to tell the type checker not to follow certain imports? That would be useful in case you have a program that tries to follow the annotation conventions for static checking but imports some library that uses annotations for a different purpose. You can probably do this already for mypy by writing a stub module.<br></div></div></div></div></blockquote><div> </div>For inline use, it may be worth defining a module level equivalent to pylint's "#pylint: skip-file" comments (rather than having each static checker come up with its own way of spelling that). Aside from that, it may also be worth recommending that static type checkers provide clear ways to control the scope of scanning (e.g. by allowing particular directories and files to be excluded, or limit scans to particular directories.<br><br>In both cases, the PEP would likely need to define the implied annotations to be assumed for excluded modules. I realised in trying to write this email that I don't currently understand the consequences of not having annotation data available for a module in terms of the ripple effects that may have on what scanners can check - from the end user perspective, I believe that's something I'd need to know, even though I wouldn't necessarily need to know *why* those were the default assumptions for unannotated operations. (I'm curious about the latter from a language *design* perspective, but I think I'd be able to use the feature effectively just by knowing the practical consequences without necessarily understanding the theory)<br><br></div></div><div class="gmail_extra">Regards,<br>Nick.<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>