[Python-ideas] Type Hinting Kick-off -- overloading

[Nick Coghlan]

On 20 December 2014 at 11:59, Guido van Rossum <guido at python.org> wrote:

> 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.
>>>
>>> https://quip.com/r69HA9GhGa7J
>>> [...]
>>>
>>
>> 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.)
>

Ugh, I hadn't fully thought through the consequences of the type
annotations being tracked separately from the assigned values when it came
to actually doing the dispatch.


> 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
> like mypy.
>

I personally like the explicit registration style used for
functools.singledispatch, but that still doesn't help with the problem of
getting access to type annotation data when *doing* the dispatch.

Perhaps it's another case like the introduction of annotations themselves,
where it may be better to leave that higher level capability out of the
initial iteration of the stdlib proposal, and instead look to standardise
it later after we have a broader base of experience with the underlying
gradual typing support?

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141220/373f040c/attachment-0001.html>