Python aka. Smalltalk Lite?

Markus Kohler kohler at
Mon Feb 14 03:27:17 EST 2000

Bijan Parsia <bparsia at> schrieb in im Newsbeitrag:
1e5yqen.1w4r3yevna9a5N%bparsia at
> Fredrik Lundh <effbot at> wrote:
> > Markus Kohler <kohler at> wrote:
> > > > seriously, what are the major shortcomings in Python
> > > > from a Smalltalk professional's perspective?
> > > -- Smalltalk's calling mechanism is much simpler than Pythons making
> > > easier to compile.
> >
> > can you elaborate?
See below ...

> Probably not, but that doesn't necessarily stop me (even *if* this was
> addressed to Markus ;))
> > as I see it, python's calling mechanism involves passing
> > a tuple (and an optional keyword dictionary) to a callable
> > object.  how does smalltalk differ from this?
> I suspect that Markus may have meant the lookup mechanism, though I'm
> not sure. I don't know that either the lookup or the call mechanism is
> "simpler" but it certainly seems *cheaper*. I.e., the cost of a method
> send is typically negligable. But I suspect that this is a
> implementation issue.

Yes the right word is "cheaper".
In Smalltalk you don't have default arguments nor you have keyword
It seems to me that implementing an efficient calling mechanism is much
easier in Smalltalk than in python.
You can just hash the name of the method to find it quickly. Another
optimization in Smalltalk is that
you cache the latest call and then just test for it directly. Since most
calls are usually monomorph this
gives you a good speedup.
By using inlined machincode to do this  Smalltalk calls
can be faster than C++ calls using a virtual table.

> > > Almost every Smalltalk implementation I have seens runs
> > > faster than Python.
> >
> > just one simple question: reading some smalltalk code makes
> > me think that smalltalk requires you to declare what instance
> > variables you're going to use?  is this true?
Yes. When you define the class using normal Smalltalk code you specify the
instance variables
without their type and without any value.

> I'm not sure what you mean. You define classes with ivars, yes. You can
> change these at anytime, including programmatically. You can catch
> message sends to non-existent methods (including calls to accessors of
> non-existent ivars) and redirect them in various ways (including by
> trapping #doesNotUnderstand:).

Yes. You even could add new ivars at runtime, because Classes are objects
too ...

> > can you add extra stuff to an instance afterwards without
> > any extra cost?

There is usually a way in Smalltalk implementations that allows you to even
change behaviour per instance and not only
per class !

> There are a variety of things you can do with a variety of costs. It's
> certainly easy enough, for example, to implemente the __get_attr__,
> __set_attr__ and friends stuff.
> > (should of course figure that out myself, but I don't seem
> > to be squeak-compatible ;-)
> Sorry to hear that. I'm sure I could help you get up and running. We
> start with a quick little brain reformat...
> Cheers,
> Bijan Parsia.


More information about the Python-list mailing list