[Python-Dev] NotImplemented reaching top-level

[Armin Rigo]

Hi,

On Mon, Dec 26, 2005 at 02:40:38AM +1000, Nick Coghlan wrote:
> That sounds like the right definition to me (I believe this behaviour is what 
> Raymond and Facundo were aiming for with the last round of updates to Decimal).

Done in patch #1390657.

Although this patch passes all existing tests plus the ones it adds,
there is a corner and untested case where it could potentially break
code.  Indeed, the only sane patch I could come up with makes
user-defined types fail to work with PySequence_Concat() and
PySequence_Repeat() -- details in the patch.  So I propose that we
clarify what these two functions really mean in term of the Python
language spec, instead of just in term of the CPython-specific sq_concat
and sq_repeat slots.  (BTW that's needed for PyPy/Jython/etc., too, to
give a reasonable meaning to the operator.concat() and operator.repeat()
built-ins.)

I propose the following definitions (which are mostly what the
docstrings already explain anyway):

* PySequence_Concat(a, b) and operator.concat(a, b) mean "a + b", with
  the difference that we check that both arguments appear to be
  sequences (as checked with operator.isSequenceType()).

* PySequence_Repeat(a, b) and operator.repeat(a, b) mean "a * b", where
  "a" is checked to be a sequence and "b" is an integer.  Some bounds
  can be enforced on "b" -- for CPython, it means that it must fit in a
  C int.

The idea is to extend PySequence_Concat() and PySequence_Repeat() to
match the above definitions precisely, which means that for objects not
defining sq_repeat or sq_concat but still appearing to be sequences,
nb_add and nb_multiply should be tried.  I don't think that this would
break existing C or Python code, but it should probably only go in 2.5,
together with the patch #1390657 that relies on it.


A bientot,

Armin