prototypes in Python [was: what is good in Prothon]

[Michele Simionato]

David MacQuigg <dmq at gain.com> wrote in message news:<sue79090tf0ja6rp63hsuj851l3dad0l44 at 4ax.com>...
> The unification of methods and functions is the one I am most interested
> in.  The code below seems to have the machinery to do that, with the
> elimination of 'self' from the argument list.  That alllows static
> methods to have exactly the same form as normal methods. ( The 'show'
> methods below are actually static methods if you remove any references
> to 'self', and replace them with explicit references, i.e.
> self.numAnimals --> Animal.numAnimals ).

Probably you do not realize that methods and functions are *already*
unified in Python: they are both examples of descriptors. Descriptors
are maybe the most important thing in Python 2.2+, since the whole new style 
object system is based on them. Not only: you can use descriptors to
implement an object system of your choice, as I did in the prototype
module; metaclasses just provide convenient syntactic sugar.

BTW, descriptors are very well discussed here:
http://users.rcn.com/python/download/Descriptor.htm

> I agree with you that Python has the capability to implement
> prototypes.  Perhaps we can do that using metaclasses for some initial
> experiments.  Then if we get some constructive feedback, we can put
> together a PEP to make prototypes part of the core language, add
> better syntax, and fix whatever might not work quite right using
> metaclasses.

Actually, I do NOT support the idea of making prototypes part of the
core language. If somebody wants to write and mantain a prototype module
that's fine, but I would be opposed to have it in the standard library.
There should be only one obvious object system in Python, and that 
object system is not a prototype based one ;)
OTOH, there is nothing wrong about having a prototype module for people
wanting to experiment with prototypes without being forced to 
abandon Python and its libraries.
 
> I'm collecting ideas for Python 3 and 4 and putting them on my webpage
> at http://ece.arizona.edu/~edatools/Python  Python 3 includes features
> that are not compatible with Python 2, but I believe are consistent to
> the extent that Python 2 programs can be automatically translated to
> Python 3.  Python 4 has no such contraint.  All that matters is that
> the language is simple and elegant, and does useful things, as opposed
> to things that are theoretically interesting.  Your comments and
> suggestions are welcome.
> 
> -- Dave

If I was writing a new language, I would do Python with prefix notation ;)

Seriously, I think that everybody interested in language design should
first study the existing languages and see what has already been
tried in the last fifty years: then probably 99% of "new" proposal
would be dismissed. I have not studied prototypes, so I may be wrong, 
but I have a gut feeling that they are not such a good idea. 

One thing I like about classes is that they are self-documenting: when you 
see a class, you know which methods are in it. Of course, you can add 
methods at run-time, but this is not good style: it is good to have the 
ability, but you should not abuse it. OTOH, in prototype languages you 
dynamically add methods all the time and the definitions are scattared in 
different places, so it is not obvious to know what an object is doing 
unless you read all the program (including imported modules). 
This is already a problem with regular inheritance, prototype inheritance
would worsen the situation, at least ISTM and IMHO.


          Michele Simionato