Unification of Methods and Functions

Michele Simionato michele.simionato at poste.it
Wed May 5 00:19:23 EDT 2004


Greg Chapman <glc at well.com> wrote in message news:<nvif90tkiv1i292600a18eqj18jd2to34a at 4ax.com>...
> On Mon, 03 May 2004 11:44:06 -0700, David MacQuigg <dmq at gain.com> wrote:
> 
> >It seems to work in Michele Simionato's 'prototype' module.
> >{ comp.lang.python, 4/28/04, "Prototypes in Python"}  It is global
> >only to the called function, but the key requirement is met -- no
> >alteration of the standard function calling sequence.
> >
> >Why can't it be a true global?
> 
> If I understand correctly, one drawback of his approach is that methods cannot
> rebind globals.  A STORE_GLOBAL opcode will store its value into the globs
> dictionary created when the method was fetched; this dictionary is not the same
> as the module's dictionary, so the changed global will only be visible within
> that method (and within that method call: the next time the method is fetched, a
> new globs will be created).
> 
> ---
> Greg Chapman

I believe you are right (haven't checked yet) but I guess I can always
change the globals from inside the method with something like

currentmodule=sys.modules["__name__"]
currentmodule.myglobal="something"

Not that changing globals from a method is good style.

BTW, I do agree that my hack is an evil hack, the interesting thing 
about it (for me) was the fact that inside the method I could use 
"super.method(*args)" instead of the ugly
"super(cls,self).method(*args)" syntax. I didn't think that was
possible at all.

I just wonder if it would be technically possible to implement
something
like that in C with a decent performance (maybe caching  the method
access).
What do you think?

        Michele Simionato



More information about the Python-list mailing list