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: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).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
[...]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 like mypy.