[Python-ideas] Terminology of types / typing [was: PEP 560 (second post)]

[Koos Zevenhoven]

On Wed, Nov 15, 2017 at 8:41 PM, Ivan Levkivskyi <levkivskyi at gmail.com>
wrote:

> ​​
> At some point it was proposed to distinguish two things: types (static)
> and classes (runtime).
> I don't think we need more fine grained terminology here.
>
>
​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.

-- Koos




> --
> Ivan
>
>
>
> On 15 November 2017 at 17:54, Koos Zevenhoven <k7hoven at gmail.com> wrote:
>
>> On Wed, Nov 15, 2017 at 1:41 PM, Koos Zevenhoven <k7hoven at gmail.com>
>> wrote:
>> [..]
>>
>>> 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.
>>>
>>>
>> ​Let me rephrase that last sentence: I think this terminology is more
>> clear.
>>
>> And here's some additional clarification:
>>
>> 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.
>>
>> 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.
>>
>> 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.
>> ​
>> ––Koos
>> ​
>>
>> --
>> + Koos Zevenhoven + http://twitter.com/k7hoven +
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>


-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171116/9ff6d175/attachment-0001.html>