On Tue, 30 Aug 2016 at 10:49 Antoine Pitrou <solip...@pitrou.net> wrote:
> On Tue, 30 Aug 2016 17:35:35 +0000
> Brett Cannon <br...@python.org> wrote:
> > >
> > > Perhaps a list would work indeed. Realistically, if there are at most
> > > 2-3 users of the field at any given time (and most probably only one or
> > > zero), a simple type check (by pointer equality) on each list item may
> > > be sufficient.
> > >
> >
> > Let's see what Maciej says, but we could standardize on switching the
> field
> > to a list when a conflict of usage is detected so the common case in the
> > frame eval function is checking for your own type, and if that fails then
> > doing a PyList_CheckExact() and look for your object, otherwise make a
> list
> > and move over to that for everyone to use. A little bit more code, but
> it's
> > simple code and takes care of conflicts only when it calls for it.
>
> That's a bit obscure and confusing, though (I *think* the weakref module
> uses a similar kludge in some place). If you want to iterate on it you
> have to write some bizarre macro to share the loop body between the two
> different code-paths (list / non-list), or some equally tedious
> function-pointer-based code.
I don't quite follow where the complexity you're suggesting comes from. The
frame evaluation function in Pyjion would just do:
if (co_extra == NULL) {
// No one using the field.
co_extra = pyjion_cache = PyPyjion_New();
}
else if (!is_pyjion_object(co_extra)) {
// Someone other than us is using the field.
if (PyList_CheckExact(co_extra)) {
// Field is already a list.
... look for object ...
if (ob_found != NULL) {
// We're in the list.
pyjion_cache = ob_found;
}
else {
// Not in the list, so add ourselves.
pyjion_cache = PyPyjion_New();
co_extra.append(pyjion_cache);
}
}
else {
// Someone else in the field, not a list (yet).
other_ob = co_extra;
co_extra = PyList_New();
co_extra.append(other_ob);
pyjion_cache = PyPyjion_New();
co_extra.append(pyjion_cache);
}
}
else {
// We're in the field.
pyjion_cache = co_extra;
}
>
> Why not make it always a list? List objects are reasonably cheap in
> memory and access time... (unlike dicts)
>
Because I would prefer to avoid any form of unnecessary performance
overhead for the common case.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
