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

On Fri, Dec 19, 2014 at 5:36 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:

...

On 20 December 2014 at 10:55, Guido van Rossum <guido@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@gmail.com | Brisbane, Australia

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

On Fri, Dec 19, 2014 at 5:36 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:

...

On 20 December 2014 at 10:55, Guido van Rossum <guido@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@gmail.com | Brisbane, Australia