Metaclass with name overloading.

[Jacek Generowicz]

Re: Metaclass with name overloading.

imbosol@aerojoc key.com (Carl Banks) writes:
[color=blue]
> def alltuple(name,b ases,clsdict):
> return tuple(clsdict.v alues())[/color]
[color=blue]
> __metaclass__ = alltuple[/color]

WBMSWA12FB !

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

[Alex Martelli]

Re: Metaclass with name overloading.

Jacek Generowicz <jacek.generowi cz@cern.ch> wrote:
[color=blue]
> aleaxit@yahoo.c om (Alex Martelli) writes:
>[color=green]
> > Jacek Generowicz <jacek.generowi cz@cern.ch> wrote:
> > ...[color=darkred]
> > > > 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.[/color]
> >
> > It's not (not in 2.4 at least)[/color]
>
> For what definition of "hard coded" ?[/color]

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.

[color=blue][color=green]
> > -- 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.[/color]
>
> So, from the perspective of trying to code it in pure Python, it _is_
> hard coded, IIUC.[/color]

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).
[color=blue]
> (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 :-( )[/color]

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]

Re: Metaclass with name overloading.

Jacek Generowicz <jacek.generowi cz@cern.ch> wrote:
[color=blue]
> imbosol@aerojoc key.com (Carl Banks) writes:
>[color=green]
> > def alltuple(name,b ases,clsdict):
> > return tuple(clsdict.v alues())
> > __metaclass__ = alltuple[/color]
>
> WBMSWA12FB !
>
> It never occurred to me that a metaclass didn't have to be a _class_.[/color]

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

Re: Metaclass with name overloading.

Jacek Generowicz <jacek.generowi cz@cern.ch> wrote:[color=blue]
> 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[/color]

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