Author phr
Recipients docs@python, gvanrossum, phr, rhettinger, veky
Date 2019-10-03.06:41:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1570084912.15.0.809646963988.issue38333@roundup.psfhosted.org>
In-reply-to
Content
At first glance, having a typeclass for each protocol (at least the widely used ones) seems fine.  It's inherent in Haskell and a lot of libraries are organized around a common set of typeclasses--look up "Typeclassopedia" for descriptions of them.  Certainly the case of abs (which you asked about by name), the typeclass is already there in the typing module.

You're right about abs(complex) returning float.  Haskell's type signature for abs is "Num a => a -> a" which means the input type is the same as the output.  That is a little bit peculiar since the abs of a complex number is complex, but we usually think of abs as a mathematical norm, which is conventionally a real.

Anyway, "abs(x: Abs[T]) -> Any"  is a better-than-nothing signature for abs, and the docs can comment a little further, and maybe someday it could even do a type-level lookup at typechecking time, i.e. have something like Haskell's "type families".

I like to think it's possible to supply reasonable signatures for most functions.  I just fixed a bug in something today because bs4 (beautiful soup 4) has no typeshed stub so mypy uses Any for functions like soup.find, instead of Optional[tag].  So the program worked fine as long as find kept returning a tag, but then crashed because it hit a document without a tag and my code didn't check for None.  That's something more precise types would have caught at mypy time.
History
Date User Action Args
2019-10-03 06:41:52phrsetrecipients: + phr, gvanrossum, rhettinger, docs@python, veky
2019-10-03 06:41:52phrsetmessageid: <1570084912.15.0.809646963988.issue38333@roundup.psfhosted.org>
2019-10-03 06:41:52phrlinkissue38333 messages
2019-10-03 06:41:51phrcreate