[Python-ideas] Improving the expressivity of function annotations

[Masklinn]

On 2011-04-04, at 14:48 , Paul Moore wrote:
> 
> Just as one example, note that even ABCs are not statically
> deterministic. Consider ABCMeta.register and ABCMeta.__subclasshook__.
ABCs can be interpreted as structural type tags, making ABCMeta.register and ABCMeta.__subclasshook__ ignorable at the cost of potential false positives (a type with the right structure would pass the static type check even if it didn't pass an issubclass check). I'm more than willing to live with that. 

> If a tool implements any form of static type checking, it will by
> definition fail to handle a certain proportion of valid Python
> programs.
Sure, static checking tools will not be able to handle some properties of Python program, but it's not like that's a new issue (there are already static checking tools for Python and they already deal with these issues via heuristics and white/black lists of members, and there is quite a history of dynamically typed languages with optional/partial/progressive static typing), and that doesn't prevent trying to get the best bang from our buck re. optional/progressive static annotations.

And the vast majority of static type systems have loopholes, Python just has far more than others.

On 2011-04-04, at 15:06 , Nick Coghlan wrote:
> If what you want is static typing, perhaps using a statically typed
> language would be a good place to start?
Mostly what I was interested in was making function annotations useful. I'm guessing they were introduced to be used yet due to the limitations I outlined their actual value falls like a rock as soon as you're using anything more complex than strings and numbers, especially if you tend to use "duck" types a lot.