[Python-ideas] Improving the expressivity of function annotations

[Masklinn]

On 2011-04-04, at 12:34 , Paul Moore wrote:
> 
> I'm not at all sure I follow your intent or terminology (structural vs
> nominative) here - perhaps you could provide a full (but short!)
> example of what you're trying to do. The above is close, but names
> like "Foo" and hiding actual implementations behind "# stuff" is
> confusing me.
Well thing is I'm hiding the implementation because it's not relevant to my proposal, which is about the function annotations and what they express (actual static checking being supposed to be implemented by third-party tools).

As to structural v nominative:

* Nominative typing is typing based on names, as in Java for instance: a type and a name are the same thing, subtypes explicitly inherit(/extend) their super types by name. In Python, this is what you do when you use isinstance (without using ABCs anyway): you check that an object has a type of a given name.

* Structural typing is basically static duck typing: you ignore names, and instead you check for "shapes". Types are seen as sets of methods (a method being a triplet of a name, an input type and an output type). So instead of checking that an object has the right type-name, you check that it has the right methods. And you can do that statically.

> If I follow what you're after, surely the #stuff in StringWriter would
> naturally raise a TypeError when you tried to use a bytes object as if
> it were a string? That's essentially what duck typing is about.
Yes, what I'm after is giving the opportunity to third-party tools, via an extension to function annotations, to statically check for this.

> If
> you're trying to enforce stricter typing (closer to the call site, the
> nearest Python can get to "compile time" type checking) then why are
> you trying to avoid ABCs? Isn't that what they are for?
Because defining ABCs is verbose, that's cool if you're going to use them quite a lot or as mixins, but defining an ABC for a single type in a single method is verbose and (for short method sets) not as clear.

And as I mentioned there's the issue of the ABC's scope: are mixin methods included in the requirements to be a subclass/instance of ABCs or not? If not, why not? If yes, doesn't that make ABCs much less useful for a huge bunch of objects in the wild?

And third, there's the issue that encoding all subsets of existing concrete types in abcs yields an exponential explosion in cases.

While not all cases are used by a long short consider the mere concept of "file-like object": some will iterate it, some will read() it, some will readline() or readlines() it, should they interact with bytes or with strings, does the file-like object need to support seek() or not, etc… These are all questions which would not be solved easily by a single ABC.

> If what you are after is not (in some sense) a Pythonic version of
> static type checking, then I apologise for misunderstanding, but could
> you clarify?
What I'm after is giving third-party tools the opportunity of structural typing, which is static duck typing.