On Sun, Jun 16, 2019 at 8:58 AM Dan Sommers <2qdxy4rzwzuui...@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 <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).
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. _______________________________________________ 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/LRZVMO74LWLX3N3BDDTQ7QRY45BHYDKW/ Code of Conduct: http://python.org/psf/codeofconduct/
