terminological obscurity

[Arthur]

On Sun, 30 May 2004 02:58:48 +0200, "Martin v. Löwis"
<martin at v.loewis.de> wrote:

>Arthur wrote:
>> Becasue I am not unwilling to see a list as an homogenous context. But
>> by placing data within that context we have done nothing to change the
>> nature of the data.  If the data was ambiguous, it is still ambiguous.
>> 
>> The purpose of the list is a perspective on the data. From that
>> perspective we view an homogenous aspect of it. 
>> 
>> Does that do?
>
>Almost. Except, in real life, it is vice versa: First, we have the
>perspective, and then we decide to represent the data in a list.

If I create different classes, with foreknowledge that instances will
serve some homogenous purpose in a list,  I am nonetheless as
interested in what distinguishes those classes as I am in that
homogenous purpose.  Otherwise they would be the same class.
And I am not unifluenced in my conceptualiztion by the knowledge that
those differences would, in programming languages much more widely
used than Python,  be considered signifcant enough to disqualify their
co-existence (without further manipulation) in sequences that are
homogenous as defined by those languages.

>
>> But if something about type is in the end at the bottom of your view,
>> than  I am still a bit lost, I am afraid.
>
>People use the word "type" to mean different things. I try to use it
>in what I consider the most generic sense, the one that is also
>defined in ISO Open Distributed Processing:
>
>"A type is a predicate"
>
>In that definition "is green" is as much a type as "has used Python
>to write software". In that sense, things in a list should share the
>same type.
>
>Other people use "type" to mean "class", but, in ODP terminology,
>a class is a template: it can be used to create objects. Those
>objects all share the same type, namely "is an instance of the
>class". So, while classes do imply types, two objects that are
>not instances of the same class may still have a same type.

I had made the point earlier in the discussion that I found it easier
to conceptualize something vaguely along these lines with old style
classes than with the new.  Mr. Lundh assured me I was talking
nonsense, but since I was talking about intuitive conceptualization,
as a user, and Fredrik seemed to be coming me at me on some technical
grounds, I rejected the characterization.

[Or else he was deadon right, but tends to express himself in a way I
take as a form of bullying.  Fredrik knows that he knows a lot more
about these issues than someone like myself, and if he is interested
in correcting a misconcpetion there are ways to do it, and ways to do
it.]

Newer Python seems to conform more to standard OOP, in concept. That
might not be true under the covers, but that is what we see.  And I
think, therefore,  there is a general expectation (or at least, I
don't think I'm alone in expecting)  that it would conform relatively
closely to standard OOP in terminology.

I certainly have no problem seeing that expectation modified.  

But until it is, it would be realistic to expect that - without
further explanation provided (and you are providing it) - that words
will be understood  in there most commonly used sense.

Ar