[Python-ideas] Terminology of types / typing [was: PEP 560 (second post)]
k7hoven at gmail.com
Wed Nov 15 06:41:17 EST 2017
Here are some thoughts––maybe even a proposal––for type-related
terminology, because clear terminology makes discussion and reasoning
easier, and helps avoid errors.
(And related to the PEP 560 thread, the question of what should go into
class attributes like __bases__).
Terminology regarding types is confusing enough, and of all the terminology
I've seen, I like these most:
* concrete type: something that concretely implements data storage or
functionality. Usually this is a normal class.
* abstract type: an assumption or set of assumptions made about an instance.
While both kinds can (and probably should) have a corresponding runtime
representation, there's not that much that we can currently assume about
the second kind––abstract types. They could be almost anything.
Anyway, regarding PEP 560, in my speculated naming, the __bases__
attribute of a class would contain both concrete and abstract bases. Those
with any concrete method implementations should go in the mro.
But then there's the problem that "abstract base classes" may contain both
concrete and abstract methods.
What do we call such a "type"? Maybe we have both "concrete" and "strictly
concrete" types. Perhaps we also have both "abstract" and "strictly
abstract" types. An ABC with some concrete default implementations might
then be both a concrete type and an abstract type.
Note that in the above bullet point "definition" of concrete type, I
intentionally left out the requirement that the type can be instantiated.
The other two bullet points are:
* strictly concrete type: a concrete type that is not abstract––it
concretely implements everything that it represents / describes. This is
almost always a normal class, so it might be also known as "class".
* strictly abstract type: an abstract type that is not concrete––it does
not implement any functionality or storage.
There might be a way to improve terminology from this, but I feel that
what I sketched here is usable but still not very ambiguous.
+ Koos Zevenhoven + http://twitter.com/k7hoven +
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas