<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif">On Wed, Nov 15, 2017 at 8:41 PM, Ivan Levkivskyi </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:levkivskyi@gmail.com" target="_blank">levkivskyi@gmail.com</a>></span><span style="font-family:arial,sans-serif"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline"></div>At some point it was proposed to distinguish two things: types (static) and classes (runtime).<br></div>I don't think we need more fine grained terminology here.<br><br></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">Yeah, well I was trying to wrap my head around this runtime vs static thing for quite some time, and it never felt quite right. I'm not sure that runtime vs static is a useful distinction at all. In the current situation of typing in python, I think it misses the point slightly. One might also say that, at static-analysis time, all types are static--including normal classes. But those correspond to concepts at runtime--abstract or concrete.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">-- Koos</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>--<br></div>Ivan<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 15 November 2017 at 17:54, Koos Zevenhoven <span dir="ltr"><<a href="mailto:k7hoven@gmail.com" target="_blank">k7hoven@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif">On Wed, Nov 15, 2017 at 1:41 PM, Koos Zevenhoven </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:k7hoven@gmail.com" target="_blank">k7hoven@gmail.com</a>></span><span style="font-family:arial,sans-serif"> wrote:</span></div><div style="font-family:monospace,monospace">[..]<span style="font-family:arial,sans-serif"> </span></div><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra" style="font-family:arial,sans-serif"><div class="gmail_extra"><div 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 style="font-family:monospace,monospace"><br></div><div 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 style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">The other two bullet points are:</div><div style="font-family:monospace,monospace"><br></div><div 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 style="font-family:monospace,monospace"><br></div><div 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 style="font-family:monospace,monospace"><br></div></div><div class="gmail_extra"><div 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><span class="m_1529216920365659656m_-244702559359003300gmail-m_-6442863051732320730HOEnZb"><font color="#888888"><div class="gmail_extra" style="font-family:arial,sans-serif"><br></div></font></span></div></div></div></blockquote><div><br></div></span><div style="font-family:monospace,monospace">Let me rephrase that last sentence: I think this terminology is more clear.</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">And here's some additional clarification:</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">I expect that the possibility of a type being both concrete and abstract may sound strange. In some ways it is indeed strange, but this overlap of concepts definitely exists already, we just need to categorize and define the concepts clearly, but without introducing too many concepts whose relations to each other are messy.</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">This might also seem strange if you are not used to how "strict" is often used in mathematics and related sciences. Essentially, it's synonymous to "proper". For example, "strict subset" and "proper subset" of a set both refer to a subset that is not the set itself. Any set is both a superset and subset of itself (in non-strict terms). Also "pure" might sometimes refer to something similar.</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">So in some sense it means excluding the "gray area". Often that "gray area" is kept part of the non-strict/improper concept for convenience. </div></div><span><div><div style="font-family:monospace,monospace"></div><div style="font-family:monospace,monospace">––Koos</div><div style="font-family:monospace,monospace"></div><br></div>-- <br><div class="m_1529216920365659656m_-244702559359003300gmail-m_-6442863051732320730gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</span></div></div>
<br></div></div>______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofco<wbr>nduct/</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div></div>