[Python-Dev] python-dev summary 2001-05-10 - 2001-05-24

[Steven D. Majewski]

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__:
> 
>   <http://mail.python.org/pipermail/python-dev/2001-May/014694.html>
> 
>  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: 
   [1] 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 
	hack.
   [2] 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