Re: Distinction between “class” and “type”

[Chris Angelico]

On Fri, May 13, 2016 at 3:07 PM, Ben Finney <ben+python at 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