[Python-Dev] python-dev summary 2001-05-10 - 2001-05-24
Steven D. Majewski
sdm7g at Virginia.EDU
Thu May 24 22:24:48 CEST 2001
On Thu, 24 May 2001, Michael Hudson wrote:
> * Type/class *
> Paul Prescod has been keeping an eye on Guido's descr-branch work,
> and posted concerns about when objects will have a __dict__:
> Then there was more technical discussion about subclassing builtin
> types and Steven Majewski evangelising prototype-based OO languages
> (though I'm not sure why!).
All you had to do was ask, Mike!
It wasn't so much evangelising protoype-based OO languages as it was
evangelising prototypes _in_ Python, and that was largely in response
to the confusion people had in trying to understand Metaclasses in
Python, and the complexity and "hacked" nature of their implementation.
( "hacked" is not meant to be insulting -- it's referring to the way
they got into Python through the back door via the "Don Beaudry hack"
-- which is actually a pretty clever trick! But clever or not, it's
not exactly straightforward. )
The suggestion (I can't quite call it a "proposal" as I really didn't
have an implementation in mind!) was to forget about all of the
Metaclass confusion, implement Prototypes as a basic type in Python,
and emulate the current Class based behavior ontop of that, but to
also expose the basic prototype level. ( I was hoping for an "Aha!"
or an implementation idea or two from someone else, but unfortunately
the concepts seem pretty new to most folks, so instead, I was drawn
into an exposition of the advantages. As you can see: drawing that
out of me is fairly easy! ;-)
Prototypes are conceptually simpler:
This is a big plus for a language that want's to teach Computer
Programming for Everybody!
I saw recently that a survey of Smalltalk newbies showed that the
single most confusing concept in the language was Metaclasses.
Prototypes can have a cleaner, simpler implementation:
However, the problem with inserting them into Python is that:
 There would still be a built-in-type/user-defined-object
split in Python that would still need a fix, so you might
well end up putting back something similar to the Beaudry
 And you would have to add back more complexity so emulate
backwards compatability of the current Class system.
So, although the implementation might be conceptually simpler,
I doubt it would save much in total.
( On the otherhand, the prototype's everything-is-an-object world
might be easier to reconcile with Python's everything-is-an-object
except-that-some-objects-are-also-class-instances view if you
could relax some of the backwards compatability requirement. )
Prototypes are behaviorally superior to classes -- i.e. the behavior
of a class based system is a subset of prototype based system.
It's a lot easier to emulate Classes in a Prototype based language
that it is to emulate Prototypes in a Class based language.
( The problem with backward compatibility I refer to above is that
there's a lot of very _specific_ implementation behavior to
duplicate if you want compatability not only with Python programs
that crawl up the __class__ hierarchy and do magic things, but
with all of the C extensions out there. Getting that right has
been a concern even with the current and less radical changes! )
In a dynamically types language like Python or Smalltalk, many of
the Patterns in the Go4 Patterns book that have non-trivial C++
implementation, become, in Python or Smalltalk, either trivial
to implement, or actually builtins of the language. The same
comparison holds for Prototype vs. Class based languages. Some of
the tricks required to specialize instance behaviour in a Class
based language become builtins or trivial to implement.
( This is, however, just as hard to get across to someone who
hasn't used a prototype based system as it is to convince
a C++ programmer who has never used a dynamic language like
Python of it's advantages. Reading all of the Self papers
counts for less here than actual programming experience! )
Classes are static, prototypes are dynamic.
The main advantage of classes in in statically typed languages,
where you need to fit fixed classes into a fixed type system.
Classes, like static types, encourage more up-front thought and
design. Also more work when you change the design.
Prototypes and dynamic types encourage diving in and hacking --
(or 'prototyping' if you're explaining it to management! ;-)
and also make refactoring and reworking code somewhat easier.
Prototypes actually fit the style of a dynamic language like Python
of Smalltalk better, but Smalltalk and C++ both got the idea from
Simula. The notion of prototypes evolved much later. Classes in
Python are a sort of historically contingent accident.
I haven't given up on the notion of a "Proto-Python" , but it seems
that, as with 'stackless' and some other radical notions, it's going
to require at least a 'proto-implementation' to convince anyone.
-- Steve Majewski
More information about the Python-list