[Python-ideas] Type Hinting Kick-off -- overloading
Guido van Rossum
guido at python.org
Sat Dec 20 02:59:52 CET 2014
On Fri, Dec 19, 2014 at 5:36 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 20 December 2014 at 10:55, Guido van Rossum <guido at python.org> wrote:
>> A few months ago we had a long discussion about type hinting. I've
>> thought a lot more about this. I've written up what I think is a decent
>> "theory" document -- writing it down like this certainly helped *me* get a
>> lot of clarity about some of the important issues.
> This looks like a great direction to me. While I know it's not the primary
> purpose, a multidispatch library built on top of it could potentially do
> wonders for cleaning up some of the ugliness in the URL parsing libraries
> (which have quite a few of those "all str, or all bytes, but not a mixture"
> style interfaces).
Right. Unfortunately we don't have a great proposal for a multidispatch
*syntax*. Here are the docs for mypy's @overload decorator
http://mypy.readthedocs.org/en/latest/function_overloading.html but the
implementation requires using peeking into the call frame's locals via
sys._getframe(). (Don't be distracted by the fact that mypy currently
doesn't record the parameter value for parameterized types, e.g.
Sequence[int] -- I have a simple enough solution for that, but it doesn't
help the overload syntax.)
The requirements for an overloading syntax are complex; it must be possible
to implement it efficiently for simple cases, but it must also support
complex overloading schemes (not everybody needs to dispatch just on str
vs. bytes :-), it must diagnose ambiguities clearly (e.g. showing near
misses if no exact match can be found, and showing what went wrong if
multiple matches apply). It must also be easy to parse for a static checker
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas