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

[David MacQuigg]

On 1 May 2004 22:34:27 -0700, michele.simionato at poste.it (Michele
Simionato) wrote:

>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.

Interesting!  I wish that unification at the primitive level had been
provided in the original design of Python.  Seems like the multiple
method styles we have now are just an historical accident.

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

Good article, but beyond my current capabilities and available time.
I'll keep this on my reference list.

>> 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 coming to the same conclusion, especially now I see that
prototypes can be done so easily in Python.  If there is serious
interest in prototypes, someone will make the effort to finish your
module and commit to maintaining it.  So far, I've seen too few
reasonable people favoring prototypes, and too many thoreticians,
egotistical fools, and anonymous trolls. :>)
 
>> 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.
>
>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. 

So many languages.  So little time. :>)  Actually, I have found my
study of Ruby and Prothon to be helpful in learning Python better, and
it re-inforced my opinion that Python is the best choice for my own
project -- a circuit-design platform that I hope will be useful for
many years.  Key factors in this choice are the excellent libraries,
third-party software, books, and large community that have been built
over the last ten years.  The flaws in Python syntax are really minor
compared to all this.

Still, I wish there was something I could do about the flaws.  From my
study of Ruby, I know that Python's string methods could be improved.
>From Prothon, I know that all forms of functions and methods could be
unified in one simple form.  It doesn't look like there is much
interest in these problems in the Python community, however, so I
think it is time to get back to my real job.

>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.

I couldn't have said it better.  With an interactive interpreter and a
good editor, it is real easy to change any class or module.  When I
want to make such a change, I don't rely on my memory to make changes
"on-the-fly".  I find that class and spend a few minutes looking at it
to make sure my changes don't have unintended consequences.  Then I
spend even longer re-running old tests to make sure I haven't broken
something totally unexpected.  The new IDLE editor is nice, because I
can just hit F5 after every edit, and it re-initializes everything.

This is not to say that "on-the-fly" programming is wrong.  It just
doesn't fit my need, which is a well-organized hierarchical system of
classes and instances, one that I can maintain, and expect others to
work on.  I just can't imagine writing something like this by sticking
in last-minute "with" blocks containing numerous variables I forgot to
put in the original class definition.

-- Dave