Strange behavior in Python 2.5a0 (trunk) --- possible error in AST?
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): print obj, v
mine = temp() mine[...] = 1 mine[0] = 1
Output from Python 2.4.2: Ellipsis 1 0 1
Output from Python 2.5a0: 0 1
In other words, the first line does nothing in Python 2.5a0.
Does anybody else see this?
Thanks,
-Travis
"Travis E. Oliphant" oliphant.travis@ieee.org 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?
class temp(object): def __setitem__(self, obj, v): print obj, v
mine = temp() mine[...] = 1
It's a compiler problem:
dis.dis(compile("mine[...] = 1", '', 'single'))
1 0 LOAD_CONST 0 (1) 3 LOAD_NAME 0 (mine) 6 LOAD_CONST 1 (Ellipsis) 9 LOAD_CONST 2 (None) 12 RETURN_VALUE
Cheers, mwh
Michael Hudson wrote:
"Travis E. Oliphant" oliphant.travis@ieee.org 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?
class temp(object): def __setitem__(self, obj, v): print obj, v
mine = temp() mine[...] = 1
It's a compiler problem:
dis.dis(compile("mine[...] = 1", '', 'single'))
1 0 LOAD_CONST 0 (1) 3 LOAD_NAME 0 (mine) 6 LOAD_CONST 1 (Ellipsis) 9 LOAD_CONST 2 (None) 12 RETURN_VALUE
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 myself, since I already wrote a test for it and worked out where to fix it)
Cheers, Nick.
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 myself, since I already wrote a test for it and worked out where to fix it)
Fabulous! The fix committed to SVN seems to work.
Now, all of numpy's unit tests are passing with Python 2.5a0.
Great work, thank you.
-Travis
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/sf/1448804
(assigned to myself, since I already wrote a test for it and worked out where to fix it)
Fabulous! The fix committed to SVN seems to work.
Now, all of numpy's unit tests are passing with Python 2.5a0.
Great work, thank you.
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.
Cheers, Nick.
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 tuple subscripts, so test_compiler can cope with the new test case.
Cheers, Nick.
participants (3)
-
Michael Hudson -
Nick Coghlan -
Travis E. Oliphant