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

David MacQuigg dmq at gain.com
Tue May 4 15:29:57 EDT 2004


On Tue, 04 May 2004 16:54:34 +1200, Greg Ewing
<greg at cosc.canterbury.ac.nz> wrote:

>David MacQuigg wrote:
>
>> On 1 May 2004 22:34:27 -0700, michele.simionato at poste.it (Michele
>> Simionato) wrote:
> >
>>>Probably you do not realize that methods and functions are *already*
>>>unified in Python: they are both examples of descriptors.
> >
>> Interesting!  I wish that unification at the primitive level had been
>> provided in the original design of Python.
>
>It was. Methods have always been no more than functions that
>happen to live in classes, and they still are. Descriptors are
>a red herring here; they're just a generalisation that allows for
>some new things. They don't unify anything that was previously
>existing but not unified.

The unification I'm talking about is what the *user* sees.  Currently
in Python , depending on the method style, you might need obj1.func()
or obj2.func(obj1) depending on the types of obj1 and obj2.  This is
unnecessary complexity.  It adds nothing to the fundamental
capabilities of the language.  All methods and functions *should* look
the same to the user.

For an example of how this *could* be done see the PrototypeSyntax
documents at http://ece.arizona.edu/~edatools/Python/  For an example
of how the presentation of OOP in Python could be cut in half, see the
Prototypes documents linked on that same page.

Ruby and Prothon got it right.  There are no special "static methods".
Python should have done the same in its original design.  Now it will
take an incompatible change in Python to fix it.  I'm hoping this will
be done in Python 3.  If not, something like Prothon will eventually
replace Python.

-- Dave




More information about the Python-list mailing list