At 12:36 AM 5/20/2006 -0600, "Steven Bethard" <[EMAIL PROTECTED]> wrote:
>On 5/20/06, Guido van Rossum <[EMAIL PROTECTED]> 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. :) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
