Re[2]: Re: class proposal

On Thu, 24 Jun 2004 03:00:01 +0200 Christian Tismer <[email protected]> wrote:

> Hi Lenard,
> 
> > 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.
> 
> All objects are objects and have a type.
> Types are objects, too, and have a type.
> type type has its base set to object.
> Types with ob_type not set to PyType_Type are types, too,
> they just have a different meta-type than others.
> I don't see overloading, yet.
>
I am separating the Python byte-code interpreter from the actual Python language.
The low level "type" system understood by the interpreter is general enough to
implemented object systems other than classic classes and new-style classes.

> > 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.
> 
> Python's bytecode interpreter had never understoof classes or
> types in any way. This was always delegated into special
> C modules.
> I still don't see the relevance of this detail. It doesn't
> matter whether you make every detail into a series of
> opcodes, or whether you compile byte code into machine code.
> That has nothing to do with the language.
>
Exactly. One could conceivably coop the Stackless Python byte-code interpeter, change
scope handling, add object level locking and a notion of self in method calls and it
it could handle the Prothon language. Both prototypes and classes could exist with no
special understanding required by the interpreter. To me Python's abstract "type" system
is simpler, more elegant, then having object "type" distinctions such as class and instance
directly handled by interpreter code. It also gives third party C module writers the
opportunity to create their own "types" by "meta-typing". Prothon has no equivanlent that
I know of. Prothon prototypes do  not give one a simpler alternative to metaclasses as
claimed. It simply does not allow it, period.

>...
> > 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.
> 
> Not really. They are mixed into it. The new-style type implementation
> detects old-style class objects and delegates to the almost unchanged
> old code, basically.
> 
> > 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
> 
> That's true for all objects.
> type has object as base:
>
In the above case isinstance is called on a classic class instance,
lower case c. But issubclass(C, object) returns False. So there appears
to be a bug with isinstance, or it was not intended for use on classic
class instances.

> [Many patient responses to my comments; these make a useful roadmap
>  for future trips into the Python source code]
>
> >>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.
> 
> Right. It doesn't know almost anything, just how to call other
> methods which know what to do.
> 
We are coming at this from two different directions. From the Python direction the details
of how new-style classes are implemented are secondary. It is internal stuff. At the
highest level C-Python has classes. I am coming at it from the Prothon direction. Prothon
is supposedly "classless". That is why the name "Prototype Python". But now the discussion
is on to add classes to Prothon. Yet the prothon interpreter lacks that low level abstract
"type" layer of C-Python. Lacking this layer the prothon interpreter will understand classes
directly. That is, the prothon interpreter will know two object types, prototypes and classes,
and treat each differently. Except for certain optimizations the Python interpreter only
understands one kind of object. It knows how to find the PyTypeObject of an object, and
it knows how to call methods of PyTypeObject. So at the root of it the Python language under
C-Python is more classless than Prothon will be.

I suppose it is like asking someone if the 8088 processor was an 8-bit or 16-bit processor
to decide if the person is hardware or software oriented. A software oriented person
answers 16-bit since the 8088 supported 16-bit instructions; a hardware oriented person would
answer 8-bit since it accessed memory one byte at a time. Looking at C-Python as a high level
language it is class base. Looking at C-Python from C extension level it is classless with class
support added on. Prothon will be a class based language at both levels (what will the C api
for class objects be like?).

I fear that Prothon is simply becoming an extended Stackless Python without the latters flexible
C-Python api. I am still wondering what advantage Prothon's distinctive interpreter design has over
Stackless Python. Prothon has no reference counting to simplify life for C module designers. But
tools like SWIG and Pyrex effective hide C-Python reference counting. And as a language Prothon
lies somewhere between Pyrex and Ruby in compatiblity with Python. At the C api level there is little
simularity. So in effect all modules added to Prothon will be written from scratch - no automatic
translation from Python. Given that Prothon is becoming more convensional with time is the extra
effort worth it? If one starts with Stackless Python and throws out the backwards compatibility
requirement what kind of language would result? Would Prothon still have its advantages?

Lenard Lindstrom
<[email protected]>