Metaclass with name overloading.

[Jacek Generowicz]

I would like to write a metaclass which would allow me to overload
names in the definition of its instances, like this

class Foo(object):

__metaclass__ = OverloadingClas s

att = 1
att = 3

def meth(self):
pass

def meth(self, arg):
return arg
I would then like the dictionary received by OverloadingClas s.__new__
to look something like this:

{'att': (1,3),
'meth: (<function meth at 0x4018e56c>, <function meth at 0x4018e80c>) }

IOW, each name bound in the class definition should have associated
with it, a tuple containing all the objects which were bound to that
name, rather merely keeping the most recent binding for any given
name.

I was wondering whether it would be possible to achieve this by
forcing Python to use some dicitonary proxy (which accumulates values,
rather that keeping just the last value to be associated with a key),
instead of dict, when executing the class definiton?

Is something like this at all possible in pure Python? or does in
require fiddling around in the guts of the parser?

[Jacek Generowicz]

im*****@aerojoc key.com (Carl Banks) writes:

def alltuple(name,b ases,clsdict):
return tuple(clsdict.v alues()) __metaclass__ = alltuple

WBMSWA12FB !

It never occurred to me that a metaclass didn't have to be a _class_.

[Alex Martelli]

Jacek Generowicz <ja************ **@cern.ch> wrote:

al*****@yahoo.c om (Alex Martelli) writes:

Jacek Generowicz <ja************ **@cern.ch> wrote:
...

> No, you can't, and it's not just a parser issue. Python uses
> direct C calls to the native dict type. It's hard coded,

I feared this would be the case.
It's not (not in 2.4 at least)

For what definition of "hard coded" ?

Is there more than one? As I already quoted on this very thread:

if (PyDict_CheckEx act(x))
err = PyDict_SetItem( x, w, v);
else
err = PyObject_SetIte m(x, w, v);

so, the "direct C call to the native dict type" only happens if x is
exactly of that type, otherwise the generic abstract call happens
instead and can deal with dispatching the functionality as needed.

Basically, the PyDict_SetItem is now there, and guarded with a
PyDict_CheckExa ct, only as an optimization: x will be of native dict
type overwhelmingly often.

-- the STORE_NAME is quite ready to find a non-dict as the frame's
f_locals. The problem is getting your object to be used as the
frame's f_locals in the first place -- hard but that only affects a
few spots in ceval.c.

So, from the perspective of trying to code it in pure Python, it _is_
hard coded, IIUC.

For some value of "it", sure, but NOT because of "direct C calls to the
native dict type" spread hither and yon (as used to be the case).
Rather, the issue is strictly with how a frame gets built and handled.

I never claimed nothing at all is hard-coded (even in 2.4), just that
the specific issue with "direct C calls" _isn't_ (in 2.4) for the case
of interest (STORE_NAME opcodes' execution).
(Unfortunately, I cannot afford the luxury of playing with the Python
implementation itself; I must deliver code which works with a
bog-standard Python 2.3.4. I'd love to have the time to play with
ceval.c on my own account ... but that is another luxury I cannot
afford :-( )

If you need to support 2.3.4 and can't even consider extensions, your
options are indeed severely limited -- I don't recall, but it's even
possible that, for THAT release, the "direct C calls" assertion is valid
(which is why I was careful to say "for 2.4 at least" every time). It
matters hugely (to most would-be extenders, who could surely afford to
use extensions for the purpose) whether it is or not, of course: making
some kind of special-purpose frame and getting it used appropriately
might be feasible, but if there are direct C calls hardwired all over
the place then no solution at all is feasible _within the 2.3.*
constraint_.
Alex

[Alex Martelli]

Jacek Generowicz <ja************ **@cern.ch> wrote:

im*****@aerojoc key.com (Carl Banks) writes:

def alltuple(name,b ases,clsdict):
return tuple(clsdict.v alues())
__metaclass__ = alltuple

WBMSWA12FB !

It never occurred to me that a metaclass didn't have to be a _class_.

You should have seen Guido's face when he first saw me give a
presentation on "use and abuse of custom metaclasses" -- apparently,
judging from his horrified expression, it hadn't occurred to him,
either, and he didn't like it half a bit... since then I've been quite
careful against actually using this idea in production code.

Actually I believed I showed something more like:

class whatever:
def __metaclass__(c lsname, clsbases, clsdict):
return <I don't remember what>
...etc etc...

i.e., an "anonymous metaclass", so to speak. But that's a minor aspect.
After all, something like:

class yetanother:
class __metaclass__(t ype):
...etc etc...

is just as so-to-speak "anonymous" yet IS nowadays quite an accepted
idiom...!
Alex

[David Mertz, Ph.D.]

Jacek Generowicz <ja************ **@cern.ch> wrote:

I would like to write a metaclass which would allow me to overload
names in the definition of its instances, like this
class Foo(object):
__metaclass__ = OverloadingClas s
def meth(self):
pass
def meth(self, arg):
return arg

It's not the literal syntax you're asking for, but using my technique
for multiple dispatch in Python achieves the effect you're looking
for. It has nothing to do with metaclass, but it lets you provide
multiple "signatures " for a call. Not just number of arguments, but
also their types (if you want: you can also generically specify a
descendent of object).

See http://www-106.ibm.com/developerwork.../l-pydisp.html
for more details.

Yours, David...