Metaclass with name overloading.

[Alex Martelli]

Jacek Generowicz <jacek.generowicz at cern.ch> wrote:

> aleaxit at yahoo.com (Alex Martelli) writes:
> 
> > Jacek Generowicz <jacek.generowicz at 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_CheckExact(x))
            err = PyDict_SetItem(x, w, v);
        else
            err = PyObject_SetItem(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_CheckExact, 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