[Python-Dev] Why is nb_inplace_add copied to sq_inplace_concat?

Matt Newell newellm at blur.com
Fri May 17 06:10:54 CEST 2013

On Thursday, May 16, 2013 08:41:32 PM you wrote:
> On Fri, May 17, 2013 at 1:38 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > On Fri, May 17, 2013 at 9:17 AM, Matt Newell <newellm at blur.com> wrote:
> >> I don't really understand what the fixup_slot_dispatchers function is
> >> doing, but it does seem like there must be a bug either in what it's
> >> doing, or in PyNumber_InPlaceAdd's handling of a NotImplemented return
> >> value from sq_inplace_concat.
> > 
> > I didn't read your post in detail, but operand precedence in CPython
> > is known to be broken for types which only populate the sq_* slots
> > without also populating the corresponding nb_* slots:
> > http://bugs.python.org/issue11477
In this case it's the other way around.  Only nb_inplace_add is populated, and 
python forces the buggy behavior that you describe below by copying 
nb_inplace_add to sq_inplace_concat. 

> Oops, I meant to state that one of the consequences of the bug is that
> returning NotImplemented from the sq_* methods doesn't work at all -
> it's never checked and thus never turned into a TypeError. That's why
> changing to delegation from the nb_* slots is the most promising
> approach - all that handling is there and correct for the numeric
> types, but pure sequence types (which can only be created from C code)
> bypass that handling.
> I *did* read enough of the original post to know that was the symptom
> you were seeing, I just failed to mention that in my initial reply...

I read through the bug and it looks like whatever solution you choose will fix 
this problem also.  

In the meantime I guess the solution for me is to always define 
sq_inplace_concat with a function that simply raises a TypeError.  Hmm, even 
simpler would be to reset sq_inplace_concat to 0 after python sets it.  I 
actually tested the latter in gdb and it gave the correct results.  I'll just 
have to keep an eye out to make sure my workaround doesn't break things when 
the real fix gets into python.


More information about the Python-Dev mailing list