Message355744
However, this is an instance of a general problem: whenever we want to strongly type (via dunders) protocols that specialcase builtin types, we will have to choose between three options:
* special case them also in typing engine, complicating the typing engine
* implement dummy dunders, puzzling readers of the code
* implement dunders that do the right thing but never actually execute, puzzling Serhiy (and probably others)
* implement dunders that are actually called (un-specialcasing builtin types), slowing down the common path
Do we have a preference for a "default" position when we encounter such problems in the future? Of course, we can override it on a case-by-case basis in the presence of good arguments, but still, a default would be nice to have.
I don't know much about static typing (which is why I loved Python until this typing craze happened:), but it seems to me that we might have another option: we can currently say that a type might be a virtual subclass of an abstract class in more than one way, right? For example, we still support old-style iterators (via __getitem__ and IndexError), IIRC. So, can we say that a type can implement numbers.Real also in two ways: by having some dunders, or by being (a literal or a subtype of) float? |
|
Date |
User |
Action |
Args |
2019-10-31 10:54:54 | veky | set | recipients:
+ veky, mark.dickinson, serhiy.storchaka, BTaskaya, bluetech |
2019-10-31 10:54:54 | veky | set | messageid: <1572519294.13.0.338887270849.issue38629@roundup.psfhosted.org> |
2019-10-31 10:54:54 | veky | link | issue38629 messages |
2019-10-31 10:54:53 | veky | create | |
|