Re[2]: Re: class proposal

I will explain here that I deliberately used the word 'type' differently
from its normal in Python meaning. This may have been a mistake. I appologize
for the confusion. I understand that the convensional Python meaning of 'type'
is a new-style class defined in C, such as 'int', 'map', and 'type' itself. But
I was at a loss for a general term for any instance of PyTypeObject, including
those that do not having ob_type set to PyType_Type. What is the correct term here?
Extension type? It would seem the word 'type' has been overloaded in Python.

My approach was to explain Python starting a the byte-code interpreter level and
working up. This was to contrast it with Prothon, and to show how "classes" in
Python are built upon a lower level "type" system which the byte-code interpreter
understands.

On Wed, 23 Jun 2004 02:27:39 +0200 Christian Tismer <[email protected]> wrote:

> Lenard Lindstrom wrote:
> 
> ...
> [skipping a lot, only commenting on what I really know about]
> 
> I'm sorry, but I have to contradict you multiple times.
> Please forgive me.
> 
> > This is where all the confusion starts. In Python types and classes are not
> > the same thing.
> 
> Wrong. In Python, there are still old-style classes which are
> slightly different in behavior, and really different because
> their type() is always class and their instance's type() is always
> instance, but they are just there for backward compatibility.
>
I use the generic meaning of 'class'. And if I am not mistaken, classic
classes in 2.2 and up are really implemented on top of new-style classes.

Python 2.3.3 (#51, Jan 27 2004, 16:30:16) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class C: pass
...
>>> c=C()
>>> isinstance(c, object)
True

> New-style classes and types are *not* different, but the same thing.
>
Again, I am using 'type' to mean any PyTypeObject instance.

> > Types are instances of an actual C structure, PyTypeObject,
> > which has pointer fields to C functions that define behaviour.
> 
> Correct.
> 
> > These are
> > sometimes called methods, but should not be confused with actual Python
> > methods, which are kept in a dictionary.
> 
> Not correct, resp. mixing topics.
> First of all, types are objects like other objects, their methods a
> really methods, and whether the methods are part of the object's
> structure or not is not relevant, since every object does this more
> or less, which is implemented in C for Python.
> All the methods of types which are exposed are also existing in
> the type's dict, and they can be overridden by Python functions.
> 
I am distinguishing between methods accessible from within Python, which
are entered in a dictionary and the C functions of a PyTypeObject instance.

>...
> > This involves accessing the object's type through pointer ob_type, then
> > calling the appropriate C function for the operation. If the function pointer
> > for the operation is NULL the operation is considered undefined and an exception
> > is raised. That is the full extent to which the python interpreter understands
> > inheritance: no multiple inheritance, no searching a type's type.
>
Again I mean byte-code interpreter.

> This is a very deep misunderstanding.
> 
> Sorry, please read typeobject.c .
>
That is my point. typeobject.c is a separate C module from ceval.c. It defines a
particular instance of PyTypeObject. PyType_Type defines new-style class behavior,
not the ( byte-code ) interpreter.

> It is correct, that every obejct has exactly one and only one type,
> and this is the primary type, which is involved in creating a new
> object and defining the internal C structure, as far as it is physically
> wired together.
> But this type can inherit from as many other types as it likes to,
> which are all collected in the bases tuple, and which have a
> type-creation-time mro list (method resolution order) which
> enumerates every other type to look into.
> 
I did leave out a lot of details. The tp_base and tp_bases slot may be defined for
PyTypeObject but does the interpreter actually use then directly, let alone know
about them? Or is it there as a convenience for the PyType_Type slot functions?
Could I define a PyTypeObject instance that does not actually use these slots?
I admit I am not clear on how new-style class types inherit through tp_base and
tp_bases. Does it involve slot promotion?

> Absolutely *YES* multiple inheritance, completely what classes had
> before, and much better.
> The basic type is object, which is common to all types and always
> compatible. All other types may or may not add to the binary basic
> object structure.

PyType_Object is inherited through the mro, not ob_type. So its importance
is only to PyTypeObject instances that are actually new-style classes.

> Multiple nheritance of types makes sure that they are binary compatible.
> That means, if you derive a type from more than one type with nontrivial
> (more than object) binary structure, then these must have a compatible
> layout. But you can always include as many types into the inheritance
> as you like, as long as they have a similar (subset) layout.
> Especially this means, you can combine at least one particular type
> with special binary layout and add as many types as you like if their
> binary layout is just object.
> 
> Example:
> 
>  >>> class a(int, str):
> ... 	pass
> ...
> Traceback (most recent call last):
>    File "<interactive input>", line 1, in ?
> TypeError: multiple bases have instance lay-out conflict
>  >>>
>
Is this enforced at the interpreter level, or by PyType_Type?

>...
> 
> > So where the prothon interpreter has to deal with multiple inheritance and
> > dictionary lookups, the python interpreter only supports single inheritance
> > and one-tier types. So which is the more complicated language?
> 
I mean the byte-code interpreter. In many cases it uses the abstract api layer, which
does not assume objects are new-style class instances. I am guessing the Prothon byte-code
interpreter instructions, in contrast, actually do implement multiple inheritance and
method resolution directly.

> Can't answer questions based upon wrong assumptions.
> 
> > Prototypes can easily be implemented using types. So can classes, as is the case
> > with Python. To suggest that the prothon interpreter should distinguish between
> > 'classes' and other objects is more object-oriented than Python. This is ironic
> > for a language that is supposed to be class free.
> 
> I have no idea if this paragraph is still related to the above
> with the corrections, because most presumptions were false.
>
I have actually implemented Prothon like prototypes in Python using new-style
classes. I had to use indirect metaclassing and override __getattribute__, etc. to
make delegation (the prototype equivalence of inheritance) work correctly, but
it is a fair approximation. A proper, production quality, version would be implemented
as an extension type. It would be a new-style class type, but would define its own
delegation system for attribute lookup.
 
> Please don't be offended, but I couldn't leave things misunderstood.
> 
That is ok. I did not have the time to confirm all the details. Yes, many PyTypeObject
instances *are* new-style classes. But this is not a requirement. And the byte-code
interpreter does not know the difference.

Lenard Lindstrom
<[email protected]>