[Python-Dev] A few questions about setobject

[Raymond Hettinger]

> > > I think it should be ok because it's never used
> > > really as a PyObject. Am I missing something? (Ok, I now thought
that
> > > maybe it's because some parts don't treat dummy elements
specially.
> > > But it seems to me that most parts do treat them specially, so
perhaps
> > > it would be better to make a few changes so that all parts will
treat
> > > them specially?)
> >
> > In principle, you are right. One place that doesn't special-case the
> > dummy is set_clear_internal (in fact, the Py_DEBUG assertion is
> > completely useless there, AFAICT).
> >
> > The tricky question is: can we be certain that we find all places,
> > in all code paths, where we have to special-case the dummy? Having
> > PyObject* which don't point to PyObject is error-prone.
> >
> > Also, what would we gain? If you think it is speed: I doubt it. In
> > one place, a comment suggests that actually seeing the dummy element
> > is so much more unlikely than the other cases that, for performance,
> > the test for the dummy is done last. We would lose additional speed
> > in the cases where the dummy isn't yet considered.
> >
> Ok, I tried. It took me 25 minutes to change the code, while going
> over every occurence of "key" and "decref" in setobject.c. (It seems
> to me that the dummy element can only be accessed from entry->key.)
> Most of the code isn't bothered by the dummy element, since it uses
> the data structure in a more abstract way. I think that it simplifies
> the code, while adding a condition in only two places, which I don't
> think should make anything noticably slower. The result passes the
> complete test suite. In one sentence: I think that it makes the code
> slightly better, and the risk is pretty low.
> 
> I thought to post it as a patch, but sourceforge didn't work for me,
> and it's not that long, so I paste it at the end of this message. Feel
> free to do whatever you want with it.

Feel free to send me your patch (as an attachment, not the body of an
email) and I'll take another look at it.

We discussed this a few months ago and rejected it.  I'll look back to
find the reason why (perhaps to keep parallel with dictobject.c or
because it was thought to be an error-prone micro-optimization).



Raymond