On 6/16/19 7:49 AM, Franklin? Lee wrote:
> On Sat, Jun 15, 2019 at 10:26 PM Guido van Rossum <gu...@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).
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/636BZAVBCDINNJI7IMHV7XVUBHV4ZKOY/
Code of Conduct: http://python.org/psf/codeofconduct/
