On Wed, Nov 15, 2017 at 8:41 PM, Ivan Levkivskyi <[email protected]> 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 <[email protected]> wrote: > >> On Wed, Nov 15, 2017 at 1:41 PM, Koos Zevenhoven <[email protected]> >> 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 >> [email protected] >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >> > -- + Koos Zevenhoven + http://twitter.com/k7hoven +
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
