On Sun, Jun 16, 2019 at 8:58 AM Dan Sommers <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
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).
The proposed feature is for expressing type relations, which only matters when you care about types. The feature will only be useful when you care about types. The syntax will only help/hurt readability when the code cares about types.