On 4 September 2016 at 19:59, Nick Coghlan <ncogh...@gmail.com> wrote:
Nick, Thank you for good suggestions. > I mostly agree, but the PEP still needs to address the fact that it's > only a subset of the benefits that actually require new syntax, since > it's that subset which provides the rationale for rejecting the use of > a function based approach, while the rest provided the incentive to > start looking for a way to replace the type comments. > I think I agree. > I suspect you'll have an easier time of it on that front if you > include some examples of dynamically typed code that a well-behaved > type-checker *must* report as correct Python code, such as: > > x: Optional[List[Any]] > # This is the type of "x" *after* the if statement, not *during* it > if arg is not None: > x = list(arg) > if other_arg is not None: > # A well-behaved typechecker should allow this due to > # the more specific initialisation in this particular branch > x.extend(other_arg) > else: > x = None There are very similar examples in PEP 484 (section on singletons in unions), we could just copy those or use this example, but I am sure Guido will not agree to word "must" (although "should" maybe possible :-) > Similarly, it would be reasonable to say that these three snippets > should all be equivalent from a typechecking perspective: > > x = None # type: Optional[T] > > x: Optional[T] = None > > x: Optional[T] > x = None > Nice idea, explicit is better than implicit. -- Ivan
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com