SupportsComplex and SupportsBytes? #68

Activity

1. gvanrossum commented on Mar 29, 2015

   

   gvanrossum

   on Mar 29, 2015

   Member

   More actions

   I'm lukewarm. I haven't really followed the use cases for SupportsInt. Also, is there a deep difference between these and collection.abc's Hashable, Iterable, Iterator, Sized, Container, which represent similar ideas but with one-off implementations? (And am I the only one confused by the fact that most of the SupportsXXX classes are named after a built-in type?)
2. JukkaL commented on Mar 31, 2015

   

   JukkaL

   on Mar 31, 2015

   ContributorAuthor

   More actions

   There is no deep difference -- they are similar to Sized. SupportsXxx means that the type can be passed to xxx(). For example, SupportsInt means that you can pass the value to int() (i.e., it defines __int__).

   If we didn't have those types, how would we specify that Decimal is a valid argument to int()? We'd have to use something like d.__int__() (if d has type Decimal) or a cast, both of which would be pretty ugly. On the other hand, there aren't that many types that can be passed to int(), so maybe that wouldn't be a big problem. Alternatively, we could allow any argument types to int, even those that would cause the call to fail at runtime.

   If we supported structural subtyping, we could easily just define internal, anonymous structural types for these functions and not expose them at all in typing. We can actually still kind of do that even without structural subtyping -- we could define types such as _SupportsInt internally and use them within our stubs (for things like Decimal), but we wouldn't allow user-defined classes to add support for int().

   I'm not attached to the naming of these types -- if I remember correctly, it was you who proposed this convention :-) I can't think of a good name similar to Sized for something that can be passed to int(). We could have something like Roundable for something that can be passed to round().
3. gvanrossum commented on Mar 31, 2015

   

   gvanrossum

   on Mar 31, 2015

   Member

   More actions

   OK, I think it's fine to add a few more, I'll add bytes and complex. If we find we need a lot more of these we should rethink this though.
4. gvanrossum commented on Mar 31, 2015

   

   gvanrossum

   on Mar 31, 2015

   Member

   More actions

   Closed by revision a8cd08d. However, I noticed that complex.__complex__ and bytes.__bytes__ don't exist. (Unlike int.__int__, float.__float__, which do exist.)
5. gvanrossum

   closed this as completedin d2d21f1on May 18, 2015
6. gvanrossum commented on May 18, 2015

   

   gvanrossum

   on May 18, 2015

   Member

   More actions

   I filed http://bugs.python.org/issue24234 for the issue about eponymous methods.