<div dir="ltr"><div class="gmail_default" style=""><div class="gmail_default" style=""><font face="monospace, monospace">Here are some thoughts––maybe even a proposal––for type-related terminology, because clear terminology makes discussion and reasoning easier, and helps avoid errors.</font></div><div class="gmail_default" style=""><font face="monospace, monospace"><br></font></div><div class="gmail_default" style=""><font face="monospace, monospace">(And related to the PEP 560 thread, the question of what should go into class attributes like __bases__).</font></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif"><br></span></div><div class="gmail_default" style="font-family:monospace,monospace">Terminology regarding types is confusing enough, and of all the terminology I've seen, I like these most:</div><div class="gmail_extra" style="font-family:arial,sans-serif"><div class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">* concrete type: something that concretely implements data storage or functionality. Usually this is a normal class.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">* abstract type: an assumption or set of assumptions made about an instance.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace">​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. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">But then there's the problem that "abstract base classes" may contain both concrete and abstract methods. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Note that in the above bullet point "definition" of concrete type, I intentionally left out the requirement that the type can be instantiated. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">The other two bullet points are:</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">* 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".</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">* strictly abstract type: an abstract type that is not concrete––it does not implement any functionality or storage.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><div class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace">​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.</div></div><div class="gmail_extra" style="font-family:arial,sans-serif"><br></div><div class="gmail_extra" style="font-family:arial,sans-serif"><br></div><div class="gmail_extra" style="font-family:arial,sans-serif"><div class="gmail_default" style="font-family:monospace,monospace">​––Koos​<br></div></div><div><br></div></div></div><div><br></div>-- <br><div class="gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div>