I'm seeing strange behavior in the Python 2.5a0 trunk that is causing
the tests for numpy to fail. Apparently obj[...] = 1 is not calling
PyObject_SetItem
Here is a minimal example to show the error. Does anyone else see this?
class temp(object):
def __setitem__(self, obj, v):
"Travis E. Oliphant" <[EMAIL PROTECTED]> writes:
> I'm seeing strange behavior in the Python 2.5a0 trunk that is causing
> the tests for numpy to fail. Apparently obj[...] = 1 is not calling
> PyObject_SetItem
>
> Here is a minimal example to show the error. Does anyone else see this?
>
> clas
Michael Hudson wrote:
> "Travis E. Oliphant" <[EMAIL PROTECTED]> writes:
>
>> I'm seeing strange behavior in the Python 2.5a0 trunk that is causing
>> the tests for numpy to fail. Apparently obj[...] = 1 is not calling
>> PyObject_SetItem
>>
>> Here is a minimal example to show the error. Does
Nick Coghlan wrote:
>
> And how...
>
>case Ellipsis_kind:
> ADDOP_O(c, LOAD_CONST, Py_Ellipsis, consts)
> break;
>
> Just a couple of minor details missing, like, oh, compiling the actual
> subscript operation :)
>
> Bug here: http://www.python.org/sf/1448804
>
> (assigned to my
Travis E. Oliphant wrote:
> Nick Coghlan wrote:
>> And how...
>>
>>case Ellipsis_kind:
>> ADDOP_O(c, LOAD_CONST, Py_Ellipsis, consts)
>> break;
>>
>> Just a couple of minor details missing, like, oh, compiling the actual
>> subscript operation :)
>>
>> Bug here: http://www.python.org
Nick Coghlan wrote:
> Unfortunately my new test case breaks test_compiler. I didn't notice because
> I
> didn't use -uall before checking it in :(
>
> If no-one else gets to it, I'll try to sort it out tonight.
OK, as of rev 43025 the compiler module also understands augmented assignment
to tu
