On 6/16/19 7:49 AM, Franklin? Lee wrote:
On Sat, Jun 15, 2019 at 10:26 PM Guido van Rossum <guido@python.org> wrote:
I don't actually know how viable this proposal is, but given that it's being debated at some length, I'd like to put in my opinion that *if* we're going to define an operator that's (roughly) synonymous with issubclass(), it should be '<:', which is used in other languages (e.g. Scala) and notational systems (https://en.wikipedia.org/wiki/Subtyping). Overloading '<=' would be easier to implement, but would also cause enough confusion that I think we should avoid it at all cost.
[...]
I don't think the proposal is viable. It might have been viable if one of these conditions were true:
1. A lot more programmers learned, from the start, to think of types as collections of their instances. Then the consistency would pay off, by reducing mental load for those programmers.
Disclaimer: I am *not* an expert on types and typing systems. That said: How would I "think of types as collections of their instances"? For example, in what sense is the type list a collection of instances of lists? Or the type int a collection of instances of integers? In my mind, a type is a description/container/shortand for a collection of properties or behaviors of instances of that type. For example, I'd much rather know that I can access a specific element of a collection by index than know that the collection is a list, or that some object can present a message to the user rather than that object being an instance of some logging class. I think that duck typing is exactly what I just described: I can have a "file-like object" that behaves like a file, whether or not it represents an actual file in a filesystem. I learned, not quite from the start, but certainly early on, that what an object *does* (i.e., its properties and behaviors) is more important than what an object *is* (i.e., its type).