trouble with the C API

Martijn Faassen m.faassen at vet.uu.nl
Fri Aug 25 18:22:50 EDT 2000


Stefan Seefeld <seefelds at magellan.umontreal.ca> wrote:
[snip]
> If I understand correctly, the situation is the following:
> You have static typing mainly for builtin types such as numbers, lists,
> dictionaries etc. and a simple 'object' for user defined types. Then, for
> user defined types, you have a totally unrelated type system based on the
> above mentioned protocols which are implemented (sequence, mapping, callable
> etc.). The latter type is infered at run time, i.e. by the interpreter while
> it tries to resolve a method call on a given object.

Right, you've discovered Python's (in)famous type/class split; one of the
goals of Python 3000 (Python's mythical successor) is to get rid of this
distinction.

To clarify a little, the run-time types (class instances) are never really
infered; there're just 'there'. When some code tries to access an attribute
of an object, Python checks whether the method is on the object, by
looking at its class (or classes), if not found, superclasses, and so 
upward, until either it's found or not. In the latter case an AttributeError
is raised. Talking about types being infered at runtime sounds more
impressive than what Python's actually doing. :)

> For C++ programmers: this compares to generic programming, i.e. templates,
> with the only difference that the types are infered/matched at compile time.

With dynamic typing, you gain lots of the power of generic programming
without the hassle that you have to go through in C++. The things
you don't gain are the static type checking and the resulting optimization
opportunities.

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?



More information about the Python-list mailing list