some random reflections of a "Python newbie": (2) language issues

[Greg Ewing]

skaller wrote:
> 
>         The 'inconsistency' I believe you are refering to is
> that there are two such 'type' representations at run time,
> and they have different properties: you can modify classes
> dynamically, and you can derived new classes, so that
> the class is 'really' the representation of the 'type'
> abstraction of the application programmer .. but when it
> comes to dictionaries, the abstraction has to be switched
> to type objects.
> 
>         This seems inconsistent to the programmer, right?

I think people are unhappy with the situation
not so much because of some theoretical notion of types, but
because of more pragmatic considerations.

Sure you can subclass from UserDict, UserList, etc. and get the
behaviour you want, most of the time. But the resulting objects
are far less efficient to use than their built-in counterparts.
One feels that there should be some way to build on the built-in
behaviour of these objects without incurring such a large
performance penalty.

Also, these "fake" objects don't always work, because some
built-in or extension functions expect to get a genuine
built-in object.

>         For example, I have previously posted an example
> Viper is going to support (it doesn't yet). It is possible
> to define a class representing
> 
>         ListOfSomething
> 
> where the 'Something' is bound when an instance is constructed:
> 
>         PyListOfInt = ListOfSomething(PyInt)

I'm curious - what is this list object actually like? Does
it share the same representation as the built-in list
object? If so, how does this come about?

There seems to be a third notion of "type" lurking behind
the scenes, namely the run-time representation of the object.
In CPython this is the C type of the data structure representing
the object, and there is a one-to-one correspondence between
TypeObjects and C structures, which the interpreter exploits
to make sure that what it's about to do is an appropriate
thing to do to this kind of C structure.

In Viper, it seems that this relationship no longer holds,
since you can plug any object in as a type object. What
ensures that the representation of an object matches what
the methods in its type object expect?

Greg