On Fri, May 13, 2016 at 3:07 PM, Ben Finney <ben+pyt...@benfinney.id.au> wrote: > This recent message from GvR, discussing a relevant PEP, advocates > keeping them separate: > > PEP 484 […] tries to make a clear terminological between classes > (the things you have at runtime) and types (the things that type > checkers care about). > > There's a big overlap because most classes are also types -- but not > the other way around! E.g. Any is a type but not a class (you can > neither inherit from Any nor instantiate it), and the same is true > for unions and type variables. […] > > <URL:https://mail.python.org/pipermail/python-ideas/2016-May/040237.html> > > As a Bear of Little Brain, this leaves me clueless. What is the > distinction Guido alludes to, and how are Python classes not also types?
The difference, as I understand it, is that types are abstract and classes are concrete. The problem is that 'type' is an actual concrete thing, so terminology is messy; but the examples are pretty clear - you can't instantiate Any the way you can instantiate str or int. There's a similar difference with ABCs like Sequence - you can't construct a Sequence, but you can document that you expect to be passed one. Maybe the solution is to have a new word for "things a type checker looks for"... except that that really does want to be, uhh, "types". Or maybe the solution is to have a new word for "things you can construct with the class keyword"... except that that that's "types" too, because they're all subclasses of 'type'. > And why is this distinction important, and who moved my cheesecake? Because it wouldn't make sense if you asked who moved your bacon. Mmm. Bacon. With cheesecake for afters. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
