Python vs. Io

Donn Cave donn at
Mon Feb 2 07:21:11 CET 2004

Quoth Paul Prescod <paul at>:
| Donn Cave wrote:
|>|> Dog barks //Io
|>|> Dog.barks() #Python
|> So, how odd that anyone would think of putting the function
|> AFTER the object.  Did this come from Forth or something?
| Dog is not just the object. It is also the namespace that "barks" comes 
| from. Both the computer and the human need to know the namespace before 
| they can interpret the meaning of the string "barks" so it seems natural 
| to me that it should come first. This is especially true in languages 
| like Python and IO where two objects of even the same type could have 
| different name->method mappings.

If as a human I need to know the namespace of a function to understand
it, am I going to be confounded if a function defined in SGMLParser
appears to be invoked on an instance of HTMLParser?  Well, honestly
that kind of thing can sometimes be a source of frustration, but in
principle we prefer to consider it a virtue of the system, right?

Taking the "feed" function there, for example -

In principle, it already could be one of

and this is fine, we're not supposed to have a problem with it.
But if the feed function had been outside this hierarchy, we would
be writing instead
   feed(parser, data)

Why isn't that a violation of the object abstraction?  Simply make
it generic and let the above notation serve in either case, and you
don't have to know the implementation in order to use it.

Now I'll admit that this level of abstraction does pose a problem
with scope and legibility, and that might have to be addressed.
My point though is that we already accept this problem as a cost
of doing OO business, so it's kind of surprising to me that OO
languages invariably stop there, instead of going all the way.
They'll proudly declare that `everything is an object', but don't
wonder about the distinction between functions and methods.

Once you get far enough down the path that you have `languages
like Python and IO', you have some semantics that would be an
awkward fit here.  Two objects of the same could have different
name->method mappings, indeed.  But it's far from obvious that
this is even a good thing, let alone the obvious evolution of OOP.

	Donn Cave, donn at

More information about the Python-list mailing list