[Python-bugs-list] [ python-Bugs-624807 ] sq_concat prevents __radd__ from working

noreply@sourceforge.net noreply@sourceforge.net
Thu, 17 Oct 2002 11:53:30 -0700


Bugs item #624807, was opened at 2002-10-17 14:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624807&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Guido van Rossum (gvanrossum)
Summary: sq_concat prevents __radd__ from working

Initial Comment:
See attached code 'bug.py'.  What's happening is if the
LHS of an inplace
add has a sq_concat or sq_inplace_concat method but it
cannot handle
the RHS argument then the operation fails rather than
trying __radd__.
I think this is related to my str.__mod__ bug.

Guido, I would appreciate any comments you have on
fiixing this problem.
Fixing this specific problem should be pretty straight
forward but I suspect
more tp_as_sequence vs. tp_as_number confusion exists.
 What's the
the longterm strategy WRT sq_concat and sq_repeat?


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-17 14:53

Message:
Logged In: YES 
user_id=6380

Boy what a mess indeed!

Most embarrassingly, this code worked in Python 2.0! :-(

I'm not sure how to fix this (and have no time to really
look into it), but I have a long-term comment.

Long-term, at the C API level, the separate notions of
"sequence repeat" and "sequence concat" should disappear,
and instead "PyNumber_Multiply" and "PyNumber_Add" should be
used. (PySequence_Repeat can stay as a shorthand that takes
a C int rather than an object).

In general, whenever two operations look the same at the
python level, there should only be one C API to invoke that,
not two. Other examples are PySequence_GetItem vs.
PyObject_GetItem.

As a transition, the built-in types should probably start
supporting the more generic ops (so strings would support
nb_add and nb_mul), and the generic API functions should
look for the numeric ops before trying the sequence or
mapping ops. (And also try the mapping ops before the --
more restrictive -- sequence ops.) Some of this is already
going on, but it would be a good policy to try and fix all
of this in 2.3. I expect it wouldn't break much -- you'd
have to have a type that interprets e.g. sq_repeat different
than nb_mul to get code breakage.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624807&group_id=5470