[Python-3000] Use cases for type annotations? (WAS: Type parameterization)

[Phillip J. Eby]

At 12:36 AM 5/20/2006 -0600, "Steven Bethard" <steven.bethard at gmail.com> wrote:

>On 5/20/06, Guido van Rossum <guido at python.org> wrote:
> > I've already addressed Steve's other issues. The blogs have the use 
> cases etc.
>
>I'm sorry, I guess I'm just dense, but here's the blogs I've read:
>
>http://www.artima.com/weblogs/viewpost.jsp?thread=85551
>http://www.artima.com/weblogs/viewpost.jsp?thread=86641
>http://www.artima.com/weblogs/viewpost.jsp?thread=87182
>http://www.artima.com/weblogs/viewpost.jsp?thread=89161
>http://www.artima.com/weblogs/viewpost.jsp?thread=101605
>http://www.artima.com/weblogs/viewpost.jsp?thread=92662
>http://www.artima.com/weblogs/viewpost.jsp?thread=155123
>
>And the only use-cases I could extract are:
>
>* optional type checking.  Lots of thoughts here, and it seemed like
>most of the blogs were leaning towards introducing interfaces to avoid
>requiring concrete types.  But the discussion here has been using
>things like 'int' and 'str', so I'm confused as to whether or not this
>is still the intention.
>
>* function overloading[1].  I think Philip J. Eby had some interesting
>thoughts here, but in all the prototypes, dispatching was done on
>concrete types.

Not true.  See Overload3K in the sandbox, per my previous posts.


>   Is there a way to do function overloading that
>doesn't rule-out duck typing and is still reasonably efficient?

Yes; see my proof-of-concept.


>I guess, in general, my concerns about the use-cases I found were that:
>
>(1) there were very few real implementations of the ideas, and
>(2) where there was an implementation, it relied on concrete types
>
>Is it the intention that type annotations be used primarily to check
>concrete types?  Or maybe interfaces are being introduced so that type
>annotations can check them instead?  If so, I'd like to see one of the
>prototype systems using interfaces.

My overloading proof of concept can be trivially extended to use any kind 
of type checking you want - as long as the checking is of an object's 
*type*, rather than of the instance involved.  Just add overloads of the 
appropriate flavor for whatever thing you plan to check.

And you're not even limited to checks against types, as long as you're 
willing to pay the price in either decreased performance or increased 
implementation complexity.  RuleDispatch, for example, can dispatch on 
arbitrary runtime tests against literally anything you care to code.  It 
offers reasonable performance at the cost of greater implementation 
complexity.  But if you don't care about performance, you can of course do 
a much simpler implementation based on the Overload3K prototype, but that 
doesn't cache type information.

Anyway, the point is that argument annotations allow you to leverage any 
number of possible systems for dispatching or argument validation, not to 
create a blessed set of semantics for them.

Another relevant use case for type annotations, by the way, is to write 
code that interfaces with statically typed languages.  For example, Jython 
and IronPython could both benefit from being able to specify types to allow 
proper overloads from Java and C# (into Python).  Likewise, ctypes and 
Pyrex could benefit from CPython having better ways to specify types.

Indeed, any kind of interface that requires external marshalling 
potentially benefits.  For example, CORBA, COM, and other RPC or "remote 
object" systems can benefit from argument annotation.  Creating a UI 
framework like the "Naked Objects" system for Java and .NET would also benefit.

And these are just the use cases for argument annotations that I can think 
of on a moment's notice.


>   Or maybe there's some other way
>that type annotations are going to be used that doesn't rely on
>concrete types that I've just missed?
>
>Sorry to still not be getting it!

I'm confused as to why nobody seems to have noticed my proposal or 
prototype.  So far my speculation is that it's outside of most people's 
ability to perceive, because it moots all the things they're arguing 
about.  That is, it makes everything way too easy for anybody to pay 
attention to it.  :)