Re[4]: Re: class proposal

On Thu, 24 Jun 2004 16:52:05 +1200 Greg Ewing <[email protected]> wrote:

> Lenard Lindstrom <[email protected]>:
> 
> > 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.
> 
> Only single inheritance exists at the C level, and it's implemented by
> copying down function pointers from the type object pointed to by
> tp_base (this happens when you initialise the type by calling
> PyType_Ready).
> 
> As far as I know, tp_bases is only used when doing a Python attribute
> lookup, and that's done by the default function installed in the
> tp_getattr slot of the type object.
> 
> It would be possible to create a type object with a different
> tp_getattr that implemented prototype behaviour instead of
> class/instance behaviour, or a different system for Python-level
> inheritance that didn't use tp_bases at all, or anything else you
> wanted.
> 
Yes. I have been wondering what would separate Prothon with classes from
Python with prototypes. Adding classes to Prothon means extending the
behaviour of its interpreter. Adding prototypes to Python just means another
module. What gives Prothon the edge is its explicit implementation of "self"
for method calls. The python interpreter has no such concept. It leads to
problems when dealing with functions as prototype attributes: is it a function
or is it a method. I know you argued for having Prothon return all function
attributes as bound methods. That is how it must be for a Python prototype.
Believe me, I know from first hand experience how frustrating that can be when
all I want is just a function.

Lenard Lindstrom
<[email protected]>