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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com