Mailman 3 May 2007 - Python-Dev

Strange behaviour with PyEval_EvalCode
by Joe Eagar May 13, 2007

May 13, 2007

Hi I'm getting extremely odd behavior. First of all, why isn't PyEval_EvalCode documented anywhere? Anyway, I'm working on blender's python integration (it embeds python, as opposed to python embedding it). I have a function that executes a string buffer of python code, fetches a function from its global dictionary then calls it. When the function code returns a local variable, PyObject_Call() appears to be returning garbage. Strangely this is only happening with internal blender types, … [View More]yet try however I might I can't find any refcounting errors to account for this. However adding an extra incref to a blender type creation function did appear to fix things and consistently return an object with reference count 1. The initial implementation used the same dictionary for the global and local dicts. I tried using separate dicts, but then the function wasn't being called at all (or at least I tested it by putting a "print "bleh"" in there, and it didn't work). Also, when I printed the refcount of the garbage data, it was garbage as well (so the entire piece of memory is bad, not just the data portion). Even more odd, the refcount of printing returned internal python types (which appears to otherwise work) steadily increase after each function call, despite being supposedly different objects. I'm not decrefing the variable in my debug versions, but nonetheless I would expect each consecutive execution of the function to return new objects with reference 1. I've tested with both python 2.4 and 2.5. Mostly with 2.4. This bug may be cropping up in other experimental blender python code as well. Here's the code in the string buffer: #BPYCONSTRAINT from Blender import * from Blender.Mathutils import * print "d" def doConstraint(inmat, tarmat, prop): a = Matrix() a.identity() a = a * TranslationMatrix(Vector(0, 0, 0)) print "t" a = tarmat return inmat print doConstraint(Matrix(), Matrix(), 0) Here's the code that executes the string buffer: PyObject *RunPython2( Text * text, PyObject * globaldict, PyObject *localdict ) { char *buf = NULL; /* The script text is compiled to Python bytecode and saved at text->compiled * to speed-up execution if the user executes the script multiple times */ if( !text->compiled ) { // if it wasn't already compiled, do it now buf = txt_to_buf( text ); text->compiled = Py_CompileString( buf, GetName( text ), Py_file_input ); MEM_freeN( buf ); if( PyErr_Occurred( ) ) { BPY_free_compiled_text( text ); return NULL; } } return PyEval_EvalCode( text->compiled, globaldict, localdict ); } . . .and heres the (rather long, and somewhat in a debugging state) function that calls the function in the script's global dictionary: void BPY_pyconstraint_eval(bPythonConstraint *con, float obmat[][4], short ownertype, void *ownerdata, float targetmat[][4]) { PyObject *srcmat, *tarmat, *idprop; PyObject *globals, *locals; PyObject *gkey, *gval; PyObject *retval; MatrixObject *retmat; Py_ssize_t ppos = 0; int row, col; if ( !con->text ) return; globals = CreateGlobalDictionary(); srcmat = newMatrixObject( (float*)obmat, 4, 4, Py_NEW ); tarmat = newMatrixObject( (float*)targetmat, 4, 4, Py_NEW ); idprop = BPy_Wrap_IDProperty( NULL, &con->prop, NULL); /* since I can't remember what the armature weakrefs do, I'll just leave this here commented out. Since this function was based on pydrivers. if( !setup_armature_weakrefs()){ fprintf( stderr, "Oops - weakref dict setup\n"); return result; } */ retval = RunPython2( con->text, globals, globals); if (retval) {Py_XDECREF( retval );} if ( retval == NULL ) { BPY_Err_Handle(con->text->id.name); ReleaseGlobalDictionary( globals ); /*free temp objects*/ Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); return; } /*Now for the fun part! Try and find the functions we need.*/ while ( PyDict_Next(globals, &ppos, &gkey, &gval) ) { if ( PyString_Check(gkey) && strcmp(PyString_AsString(gkey), "doConstraint")==0 ) { if (PyFunction_Check(gval) ) { retval = PyObject_CallObject(gval, Py_BuildValue("OOO", srcmat, tarmat, idprop)); Py_XDECREF( retval ); } else { printf("ERROR: doConstraint is supposed to be a function!\n"); } break; } } if (!retval) { BPY_Err_Handle(con->text->id.name); /*free temp objects*/ ReleaseGlobalDictionary( globals ); Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); return; } if (!PyObject_TypeCheck(retval, &matrix_Type)) { printf("Error in pyconstraint: Wrong return type for a pyconstraint!\n"); ReleaseGlobalDictionary( globals ); Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); Py_XDECREF( retval ); return; } retmat = (MatrixObject*) retval; if (retmat->rowSize != 4 || retmat->colSize != 4) { printf("Error in pyconstraint: Matrix is the wrong size!\n"); ReleaseGlobalDictionary( globals ); Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); Py_XDECREF( retval ); return; } //this is the reverse of code taken from newMatrix(). for(row = 0; row < 4; row++) { for(col = 0; col < 4; col++) { if (retmat->wrapped) obmat[row][col] = retmat->data.blend_data[row*4+col]; //[row][col]; else obmat[row][col] = retmat->data.py_data[row*4+col]; //[row][col]; } } /*clear globals*/ //ReleaseGlobalDictionary( globals ); /*free temp objects*/ //Py_XDECREF( idprop ); //Py_XDECREF( srcmat ); //Py_XDECREF( tarmat ); //Py_XDECREF( retval ); //PyDict_Clear(locals); //Py_XDECREF(locals); } Joe [View Less]

1 1

Strange behaviour with PyEval_EvalCode
by Joe Eagar May 13, 2007

May 13, 2007

Hi I'm getting extremely odd behavior. First of all, why isn't PyEval_EvalCode documented anywhere? Anyway, I'm working on blender's python integration (it embeds python, as opposed to python embedding it). I have a function that executes a string buffer of python code, fetches a function from its global dictionary then calls it. When the function code returns a local variable, PyObject_Call() appears to be returning garbage. Strangely this is only happening with internal blender types, … [View More]yet try however I might I can't find any refcounting errors to account for this. The initial implementation used the same dictionary for the global and local dicts. I tried using separate dicts, but then the function wasn't being called at all (or at least I tested it by putting a "print "bleh"" in there, and it didn't work). Also, when I printed the refcount of the garbage data, it was garbage as well (so the entire piece of memory is bad, not just the data portion). I've tested with both python 2.4 and 2.5. Mostly with 2.4. This bug may be cropping up in other experimental blender python code as well. Here's the code in the string buffer: #BPYCONSTRAINT from Blender import * from Blender.Mathutils import * print "d" def doConstraint(inmat, tarmat, prop): a = Matrix() a.identity() a = a * TranslationMatrix(Vector(0, 0, 0)) print "t" a = tarmat return inmat print doConstraint(Matrix(), Matrix(), 0) Here's the code that executes the string buffer: PyObject *RunPython2( Text * text, PyObject * globaldict, PyObject *localdict ) { char *buf = NULL; /* The script text is compiled to Python bytecode and saved at text->compiled * to speed-up execution if the user executes the script multiple times */ if( !text->compiled ) { // if it wasn't already compiled, do it now buf = txt_to_buf( text ); text->compiled = Py_CompileString( buf, GetName( text ), Py_file_input ); MEM_freeN( buf ); if( PyErr_Occurred( ) ) { BPY_free_compiled_text( text ); return NULL; } } return PyEval_EvalCode( text->compiled, globaldict, localdict ); } . . .and heres the (rather long, and somewhat in a debugging state) function that calls the function in the script's global dictionary: void BPY_pyconstraint_eval(bPythonConstraint *con, float obmat[][4], short ownertype, void *ownerdata, float targetmat[][4]) { PyObject *srcmat, *tarmat, *idprop; PyObject *globals, *locals; PyObject *gkey, *gval; PyObject *retval; MatrixObject *retmat; Py_ssize_t ppos = 0; int row, col; if ( !con->text ) return; globals = CreateGlobalDictionary(); srcmat = newMatrixObject( (float*)obmat, 4, 4, Py_NEW ); tarmat = newMatrixObject( (float*)targetmat, 4, 4, Py_NEW ); idprop = BPy_Wrap_IDProperty( NULL, &con->prop, NULL); /* since I can't remember what the armature weakrefs do, I'll just leave this here commented out. Since this function was based on pydrivers. if( !setup_armature_weakrefs()){ fprintf( stderr, "Oops - weakref dict setup\n"); return result; } */ retval = RunPython2( con->text, globals, globals); if (retval) {Py_XDECREF( retval );} if ( retval == NULL ) { BPY_Err_Handle(con->text->id.name); ReleaseGlobalDictionary( globals ); /*free temp objects*/ Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); return; } /*Now for the fun part! Try and find the functions we need.*/ while ( PyDict_Next(globals, &ppos, &gkey, &gval) ) { if ( PyString_Check(gkey) && strcmp(PyString_AsString(gkey), "doConstraint")==0 ) { if (PyFunction_Check(gval) ) { retval = PyObject_CallObject(gval, Py_BuildValue("OOO", srcmat, tarmat, idprop)); Py_XDECREF( retval ); } else { printf("ERROR: doConstraint is supposed to be a function!\n"); } break; } } if (!retval) { BPY_Err_Handle(con->text->id.name); /*free temp objects*/ ReleaseGlobalDictionary( globals ); Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); return; } if (!PyObject_TypeCheck(retval, &matrix_Type)) { printf("Error in pyconstraint: Wrong return type for a pyconstraint!\n"); ReleaseGlobalDictionary( globals ); Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); Py_XDECREF( retval ); return; } retmat = (MatrixObject*) retval; if (retmat->rowSize != 4 || retmat->colSize != 4) { printf("Error in pyconstraint: Matrix is the wrong size!\n"); ReleaseGlobalDictionary( globals ); Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); Py_XDECREF( retval ); return; } //this is the reverse of code taken from newMatrix(). for(row = 0; row < 4; row++) { for(col = 0; col < 4; col++) { if (retmat->wrapped) obmat[row][col] = retmat->data.blend_data[row*4+col]; //[row][col]; else obmat[row][col] = retmat->data.py_data[row*4+col]; //[row][col]; } } /*clear globals*/ //ReleaseGlobalDictionary( globals ); /*free temp objects*/ //Py_XDECREF( idprop ); //Py_XDECREF( srcmat ); //Py_XDECREF( tarmat ); //Py_XDECREF( retval ); //PyDict_Clear(locals); //Py_XDECREF(locals); } Joe [View Less]

3 2

generators and with
by tomer filiba May 13, 2007

May 13, 2007

why not add __enter__ and __exit__ to generator objects? it's really a trivial addition: __enter__ returns self, __exit__ calls close(). it would be used to ensure close() is called when the generator is disposed, instead of doing that manually. typical usage would be: with mygenerator() as g: g.next() bar = g.send("foo") -tomer

3 2

Re: [Python-Dev] New operations in Decimal
by Raymond Hettinger May 12, 2007

May 12, 2007

| > Am I losing my marbles, or is this a proposal to add the logical | > operations to FLOATING-POINT? | | Sort of. This is a proposal to keep compliant with the General Decimal | Arithmetic Specification, as we promised. | | http://www2.hursley.ibm.com/decimal/ > I oppose adding this illogical nonsense to Python. Who would ever use it? Doesn't matter. What is more important is that we provide a module that is fully compliant with the specification and passes all of its tests. … [View More]

5 6

Re: [Python-Dev] New operations in Decimal
by Nick Maclaren May 10, 2007

May 10, 2007

Ronald Oussoren <ronaldoussoren(a)mac.com> wrote: > On 27 Apr, 2007, at 20:39, Facundo Batista wrote: > > > - and (and), or (or), xor (xor) [CD]: Takes two logical operands, the > > result is the logical operation applied between each digit. > > "and" and "or" are keywords, you can't have methods with those names: Am I losing my marbles, or is this a proposal to add the logical operations to FLOATING-POINT? I may have missed a previous posting, in which case … [View More]

3 2

Hard-to-find problem with set().test_c_api()
by Guido van Rossum May 10, 2007

May 10, 2007

Could anyone help me debug the following? This is in a debug build of the trunk. I've been banging my head against the wrong wall for too long to "see" the issue here... :-( $ ./python -S -c "set('abc').test_c_api()" [6872 refs] Fatal Python error: ../Objects/stringobject.c:4971 object at 0xb7f66ca0 has negative ref count -606348326 Aborted -- --Guido van Rossum (home page: http://www.python.org/~guido/)

1 1

Strange behaviour with PyEval_EvalCode
by Joe Eagar May 10, 2007

May 10, 2007

[I'm re-sending this message cause it might've gotten lost; sorry if it ends up posting twice] Hi I'm getting extremely odd behavior. First of all, why isn't PyEval_EvalCode documented anywhere? Anyway, I'm working on blender's python integration (it embeds python, as opposed to python embedding it). I have a function that executes a string buffer of python code, fetches a function from its global dictionary then calls it. When the function code returns a local variable, PyObject_Call() … [View More]appears to be returning garbage. The initial implementation used the same dictionary for the global and local dicts. I tried using separate dicts, but then the function wasn't being called at all (or at least I tested it by putting a "print "bleh"" in there, and it didn't work). I've tested with both python 2.4 and 2.5. Mostly with 2.4. This bug may be cropping up in other experimental blender python code as well. Here's the code in the string buffer: #BPYCONSTRAINT from Blender import * from Blender.Mathutils import * print "d" def doConstraint(inmat, tarmat, prop): a = Matrix() a.identity() a = a * TranslationMatrix(Vector(0, 0, 0)) print "t" a = tarmat return inmat print doConstraint(Matrix(), Matrix(), 0) Here's the code that executes the string buffer: PyObject *RunPython2( Text * text, PyObject * globaldict, PyObject *localdict ) { char *buf = NULL; /* The script text is compiled to Python bytecode and saved at text->compiled * to speed-up execution if the user executes the script multiple times */ if( !text->compiled ) { // if it wasn't already compiled, do it now buf = txt_to_buf( text ); text->compiled = Py_CompileString( buf, GetName( text ), Py_file_input ); MEM_freeN( buf ); if( PyErr_Occurred( ) ) { BPY_free_compiled_text( text ); return NULL; } } return PyEval_EvalCode( text->compiled, globaldict, localdict ); } . . .and heres the (rather long, and somewhat in a working state) function that calls the function in the script's global dictionary: void BPY_pyconstraint_eval(bPythonConstraint *con, float obmat[][4], short ownertype, void *ownerdata, float targetmat[][4]) { PyObject *srcmat, *tarmat, *idprop; PyObject *globals, *locals; PyObject *gkey, *gval; PyObject *retval; MatrixObject *retmat; Py_ssize_t ppos = 0; int row, col; if ( !con->text ) return; globals = CreateGlobalDictionary(); srcmat = newMatrixObject( (float*)obmat, 4, 4, Py_NEW ); tarmat = newMatrixObject( (float*)targetmat, 4, 4, Py_NEW ); idprop = BPy_Wrap_IDProperty( NULL, &con->prop, NULL); /* since I can't remember what the armature weakrefs do, I'll just leave this here commented out. Since this function was based on pydrivers. if( !setup_armature_weakrefs()){ fprintf( stderr, "Oops - weakref dict setup\n"); return result; } */ retval = RunPython2( con->text, globals, globals); if (retval) {Py_XDECREF( retval );} if ( retval == NULL ) { BPY_Err_Handle(con->text->id.name); ReleaseGlobalDictionary( globals ); /*free temp objects*/ Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); return; } /*Now for the fun part! Try and find the functions we need.*/ while ( PyDict_Next(globals, &ppos, &gkey, &gval) ) { if ( PyString_Check(gkey) && strcmp(PyString_AsString(gkey), "doConstraint")==0 ) { if (PyFunction_Check(gval) ) { retval = PyObject_CallObject(gval, Py_BuildValue("OOO", srcmat, tarmat, idprop)); Py_XDECREF( retval ); } else { printf("ERROR: doConstraint is supposed to be a function!\n"); } break; } } if (!retval) { BPY_Err_Handle(con->text->id.name); /*free temp objects*/ ReleaseGlobalDictionary( globals ); Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); return; } if (!PyObject_TypeCheck(retval, &matrix_Type)) { printf("Error in pyconstraint: Wrong return type for a pyconstraint!\n"); ReleaseGlobalDictionary( globals ); Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); Py_XDECREF( retval ); return; } retmat = (MatrixObject*) retval; if (retmat->rowSize != 4 || retmat->colSize != 4) { printf("Error in pyconstraint: Matrix is the wrong size!\n"); ReleaseGlobalDictionary( globals ); Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); Py_XDECREF( retval ); return; } //this is the reverse of code taken from newMatrix(). for(row = 0; row < 4; row++) { for(col = 0; col < 4; col++) { if (retmat->wrapped) obmat[row][col] = retmat->data.blend_data[row*4+col]; //[row][col]; else obmat[row][col] = retmat->data.py_data[row*4+col]; //[row][col]; } } /*clear globals*/ //ReleaseGlobalDictionary( globals ); /*free temp objects*/ //Py_XDECREF( idprop ); //Py_XDECREF( srcmat ); //Py_XDECREF( tarmat ); //Py_XDECREF( retval ); //PyDict_Clear(locals); //Py_XDECREF(locals); } Joe [View Less]

1 0

\code or \constant in tex markup
by Neal Norwitz May 10, 2007

May 10, 2007

Which is correct? $ egrep '(False|True)' Doc/lib/*.tex | grep -c \\constant{ 74 $ egrep '(False|True)' Doc/lib/*.tex | grep -c \\code{ 204 $ egrep 'None' Doc/lib/*.tex | grep -c \\code{ 512 $ egrep 'None' Doc/lib/*.tex | grep -c \\constant{ 83 n

2 1

Strange behaviour with PyEval_EvalCode
by Joe Eagar May 10, 2007

May 10, 2007

[I'm re-sending this message cause it might've gotten lost; sorry if it ends up posting twice] Hi I'm getting extremely odd behavior. First of all, why isn't PyEval_EvalCode documented anywhere? Anyway, I'm working on blender's python integration (it embeds python, as opposed to python embedding it). I have a function that executes a string buffer of python code, fetches a function from its global dictionary then calls it. When the function code returns a local variable, PyObject_Call() … [View More]appears to be returning garbage. The initial implementation used the same dictionary for the global and local dicts. I tried using separate dicts, but then the function wasn't being called at all (or at least I tested it by putting a "print "bleh"" in there, and it didn't work). I've tested with both python 2.4 and 2.5. Mostly with 2.4. This bug may be cropping up in other experimental blender python code as well. Here's the code in the string buffer: #BPYCONSTRAINT from Blender import * from Blender.Mathutils import * print "d" def doConstraint(inmat, tarmat, prop): a = Matrix() a.identity() a = a * TranslationMatrix(Vector(0, 0, 0)) print "t" a = tarmat return inmat print doConstraint(Matrix(), Matrix(), 0) Here's the code that executes the string buffer: PyObject *RunPython2( Text * text, PyObject * globaldict, PyObject *localdict ) { char *buf = NULL; /* The script text is compiled to Python bytecode and saved at text->compiled * to speed-up execution if the user executes the script multiple times */ if( !text->compiled ) { // if it wasn't already compiled, do it now buf = txt_to_buf( text ); text->compiled = Py_CompileString( buf, GetName( text ), Py_file_input ); MEM_freeN( buf ); if( PyErr_Occurred( ) ) { BPY_free_compiled_text( text ); return NULL; } } return PyEval_EvalCode( text->compiled, globaldict, localdict ); } . . .and heres the (rather long, and somewhat in a working state) function that calls the function in the script's global dictionary: void BPY_pyconstraint_eval(bPythonConstraint *con, float obmat[][4], short ownertype, void *ownerdata, float targetmat[][4]) { PyObject *srcmat, *tarmat, *idprop; PyObject *globals, *locals; PyObject *gkey, *gval; PyObject *retval; MatrixObject *retmat; Py_ssize_t ppos = 0; int row, col; if ( !con->text ) return; globals = CreateGlobalDictionary(); srcmat = newMatrixObject( (float*)obmat, 4, 4, Py_NEW ); tarmat = newMatrixObject( (float*)targetmat, 4, 4, Py_NEW ); idprop = BPy_Wrap_IDProperty( NULL, &con->prop, NULL); /* since I can't remember what the armature weakrefs do, I'll just leave this here commented out. Since this function was based on pydrivers. if( !setup_armature_weakrefs()){ fprintf( stderr, "Oops - weakref dict setup\n"); return result; } */ retval = RunPython2( con->text, globals, globals); if (retval) {Py_XDECREF( retval );} if ( retval == NULL ) { BPY_Err_Handle(con->text->id.name); ReleaseGlobalDictionary( globals ); /*free temp objects*/ Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); return; } /*Now for the fun part! Try and find the functions we need.*/ while ( PyDict_Next(globals, &ppos, &gkey, &gval) ) { if ( PyString_Check(gkey) && strcmp(PyString_AsString(gkey), "doConstraint")==0 ) { if (PyFunction_Check(gval) ) { retval = PyObject_CallObject(gval, Py_BuildValue("OOO", srcmat, tarmat, idprop)); Py_XDECREF( retval ); } else { printf("ERROR: doConstraint is supposed to be a function!\n"); } break; } } if (!retval) { BPY_Err_Handle(con->text->id.name); /*free temp objects*/ ReleaseGlobalDictionary( globals ); Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); return; } if (!PyObject_TypeCheck(retval, &matrix_Type)) { printf("Error in pyconstraint: Wrong return type for a pyconstraint!\n"); ReleaseGlobalDictionary( globals ); Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); Py_XDECREF( retval ); return; } retmat = (MatrixObject*) retval; if (retmat->rowSize != 4 || retmat->colSize != 4) { printf("Error in pyconstraint: Matrix is the wrong size!\n"); ReleaseGlobalDictionary( globals ); Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); Py_XDECREF( retval ); return; } //this is the reverse of code taken from newMatrix(). for(row = 0; row < 4; row++) { for(col = 0; col < 4; col++) { if (retmat->wrapped) obmat[row][col] = retmat->data.blend_data[row*4+col]; //[row][col]; else obmat[row][col] = retmat->data.py_data[row*4+col]; //[row][col]; } } /*clear globals*/ //ReleaseGlobalDictionary( globals ); /*free temp objects*/ //Py_XDECREF( idprop ); //Py_XDECREF( srcmat ); //Py_XDECREF( tarmat ); //Py_XDECREF( retval ); //PyDict_Clear(locals); //Py_XDECREF(locals); } Joe [View Less]

1 0

Strange behaviour with PyEval_EvalCode
by Joe Eagar May 10, 2007

May 10, 2007

Hi I'm getting extremely odd behavior. First of all, why isn't PyEval_EvalCode documented anywhere? Anyway, I'm working on blender's python integration (it embeds python, as opposed to python embedding it). I have a function that executes a string buffer of python code, fetches a function from its global dictionary then calls it. When the function code returns a local variable, PyObject_Call() appears to be returning garbage. The initial implementation used the same dictionary for … [View More]the global and local dicts. I tried using separate dicts, but then the function wasn't being called at all (or at least I tested it by putting a "print "bleh"" in there, and it didn't work). I've tested with both python 2.4 and 2.5. Mostly with 2.4. This bug may be cropping up in other experimental blender python code as well. Here's the code in the string buffer: #BPYCONSTRAINT from Blender import * from Blender.Mathutils import * print "d" def doConstraint(inmat, tarmat, prop): a = Matrix() a.identity() a = a * TranslationMatrix(Vector(0, 0, 0)) print "t" a = tarmat return inmat print doConstraint(Matrix(), Matrix(), 0) Here's the code that executes the string buffer: PyObject *RunPython2( Text * text, PyObject * globaldict, PyObject *localdict ) { char *buf = NULL; /* The script text is compiled to Python bytecode and saved at text->compiled * to speed-up execution if the user executes the script multiple times */ if( !text->compiled ) { // if it wasn't already compiled, do it now buf = txt_to_buf( text ); text->compiled = Py_CompileString( buf, GetName( text ), Py_file_input ); MEM_freeN( buf ); if( PyErr_Occurred( ) ) { BPY_free_compiled_text( text ); return NULL; } } return PyEval_EvalCode( text->compiled, globaldict, localdict ); } . . .and heres the (rather long, and somewhat in a working state) function that calls the function in the script's global dictionary: void BPY_pyconstraint_eval(bPythonConstraint *con, float obmat[][4], short ownertype, void *ownerdata, float targetmat[][4]) { PyObject *srcmat, *tarmat, *idprop; PyObject *globals, *locals; PyObject *gkey, *gval; PyObject *retval; MatrixObject *retmat; Py_ssize_t ppos = 0; int row, col; if ( !con->text ) return; globals = CreateGlobalDictionary(); srcmat = newMatrixObject( (float*)obmat, 4, 4, Py_NEW ); tarmat = newMatrixObject( (float*)targetmat, 4, 4, Py_NEW ); idprop = BPy_Wrap_IDProperty( NULL, &con->prop, NULL); /* since I can't remember what the armature weakrefs do, I'll just leave this here commented out. Since this function was based on pydrivers. if( !setup_armature_weakrefs()){ fprintf( stderr, "Oops - weakref dict setup\n"); return result; } */ retval = RunPython2( con->text, globals, globals); if (retval) {Py_XDECREF( retval );} if ( retval == NULL ) { BPY_Err_Handle(con->text->id.name); ReleaseGlobalDictionary( globals ); /*free temp objects*/ Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); return; } /*Now for the fun part! Try and find the functions we need.*/ while ( PyDict_Next(globals, &ppos, &gkey, &gval) ) { if ( PyString_Check(gkey) && strcmp(PyString_AsString(gkey), "doConstraint")==0 ) { if (PyFunction_Check(gval) ) { retval = PyObject_CallObject(gval, Py_BuildValue("OOO", srcmat, tarmat, idprop)); Py_XDECREF( retval ); } else { printf("ERROR: doConstraint is supposed to be a function!\n"); } break; } } if (!retval) { BPY_Err_Handle(con->text->id.name); /*free temp objects*/ ReleaseGlobalDictionary( globals ); Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); return; } if (!PyObject_TypeCheck(retval, &matrix_Type)) { printf("Error in pyconstraint: Wrong return type for a pyconstraint!\n"); ReleaseGlobalDictionary( globals ); Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); Py_XDECREF( retval ); return; } retmat = (MatrixObject*) retval; if (retmat->rowSize != 4 || retmat->colSize != 4) { printf("Error in pyconstraint: Matrix is the wrong size!\n"); ReleaseGlobalDictionary( globals ); Py_XDECREF( idprop ); Py_XDECREF( srcmat ); Py_XDECREF( tarmat ); Py_XDECREF( retval ); return; } //this is the reverse of code taken from newMatrix(). for(row = 0; row < 4; row++) { for(col = 0; col < 4; col++) { if (retmat->wrapped) obmat[row][col] = retmat->data.blend_data[row*4+col]; //[row][col]; else obmat[row][col] = retmat->data.py_data[row*4+col]; //[row][col]; } } /*clear globals*/ //ReleaseGlobalDictionary( globals ); /*free temp objects*/ //Py_XDECREF( idprop ); //Py_XDECREF( srcmat ); //Py_XDECREF( tarmat ); //Py_XDECREF( retval ); //PyDict_Clear(locals); //Py_XDECREF(locals); } Joe [View Less]

1 0

best practices stdlib: purging xrange
by Anthony Baxter May 10, 2007

May 10, 2007

I'd like to suggest that we remove all (or nearly all) uses of xrange from the stdlib. A quick scan shows that most of the usage of it is unnecessary. With it going away in 3.0, and it being informally deprecated anyway, it seems like a good thing to go away where possible. Any objections? Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

8 10

svn logs
by Kristján Valur Jónsson May 9, 2007

May 9, 2007

Hello there. Does anyone know why getting the SVN logs for a project is so excruciatingly slow? Is this an inherent SVN problem or are the python.org servers simply overloaded? It takes something like 10 minutes for me to get the log messages window up for the root of a branch. Cheers, Kristján

4 3

Re: [Python-Dev] Changing string constants to byte arrays ([Python-checkins] r55119 - in python/branches/py3k-struni/Lib: codecs.py test/test_codecs.py)
by M.-A. Lemburg May 8, 2007

May 8, 2007

Hi Walter, if the bytes type does turn out to be a mutable type as suggested in PEP 358, then please make sure that no code (C code in particular), relies on the constantness of these byte objects. This is especially important when it comes to codecs, since the error callback logic would allow the callback to manipulate the byte object contents and length without the codec taking note of this change. I expect there to be other places in the interpreter which would break as well. Otherwise, … [View More]

13 20

PEP 30XZ: Simplified Parsing
by Jim Jewett May 8, 2007

May 8, 2007

PEP: 30xz Title: Simplified Parsing Version: $Revision$ Last-Modified: $Date$ Author: Jim J. Jewett <JimJJewett(a)gmail.com> Status: Draft Type: Standards Track Content-Type: text/plain Created: 29-Apr-2007 Post-History: 29-Apr-2007 Abstract Python initially inherited its parsing from C. While this has been generally useful, there are some remnants which have been less useful for python, and should be eliminated. + Implicit String concatenation + Line … [View More]continuation with "\" + 034 as an octal number (== decimal 28). Note that this is listed only for completeness; the decision to raise an Exception for leading zeros has already been made in the context of PEP XXX, about adding a binary literal. Rationale for Removing Implicit String Concatenation Implicit String concatentation can lead to confusing, or even silent, errors. [1] def f(arg1, arg2=None): pass f("abc" "def") # forgot the comma, no warning ... # silently becomes f("abcdef", None) or, using the scons build framework, sourceFiles = [ 'foo.c', 'bar.c', #...many lines omitted... 'q1000x.c'] It's a common mistake to leave off a comma, and then scons complains that it can't find 'foo.cbar.c'. This is pretty bewildering behavior even if you *are* a Python programmer, and not everyone here is. Note that in C, the implicit concatenation is more justified; there is no other way to join strings without (at least) a function call. In Python, strings are objects which support the __add__ operator; it is possible to write: "abc" + "def" Because these are literals, this addition can still be optimized away by the compiler. Guido indicated [2] that this change should be handled by PEP, because there were a few edge cases with other string operators, such as the %. The resolution is to treat them the same as today. ("abc %s def" + "ghi" % var) # fails like today. # raises TypeError because of # precedence. (% before +) ("abc" + "def %s ghi" % var) # works like today; precedence makes # the optimization more difficult to # recognize, but does not change the # semantics. ("abc %s def" + "ghi") % var # works like today, because of # precedence: () before % # CPython compiler can already # add the literals at compile-time. Rationale for Removing Explicit Line Continuation A terminal "\" indicates that the logical line is continued on the following physical line (after whitespace). Note that a non-terminal "\" does not have this meaning, even if the only additional characters are invisible whitespace. (Python depends heavily on *visible* whitespace at the beginning of a line; it does not otherwise depend on *invisible* terminal whitespace.) Adding whitespace after a "\" will typically cause a syntax error rather than a silent bug, but it still isn't desirable. The reason to keep "\" is that occasionally code looks better with a "\" than with a () pair. assert True, ( "This Paren is goofy") But realistically, that paren is no worse than a "\". The only advantage of "\" is that it is slightly more familiar to users of C-based languages. These same languages all also support line continuation with (), so reading code will not be a problem, and there will be one less rule to learn for people entirely new to programming. Rationale for Removing Implicit Octal Literals This decision should be covered by PEP ???, on numeric literals. It is mentioned here only for completeness. C treats integers beginning with "0" as octal, rather than decimal. Historically, Python has inherited this usage. This has caused quite a few annoying bugs for people who forgot the rule, and tried to line up their constants. a = 123 b = 024 # really only 20, because octal c = 245 In Python 3.0, the second line will instead raise a SyntaxError, because of the ambiguity. Instead, the line should be written as in one of the following ways: b = 24 # PEP 8 b = 24 # columns line up, for quick scanning b = 0t24 # really did want an Octal! References [1] Implicit String Concatenation, Jewett, Orendorff http://mail.python.org/pipermail/python-ideas/2007-April/000397.html [2] PEP 12, Sample reStructuredText PEP Template, Goodger, Warsaw http://www.python.org/peps/pep-0012 [3] http://www.opencontent.org/openpub/ Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: [View Less]

26 33

Re: [Python-Dev] best practices stdlib: purging xrange
by Raymond Hettinger May 8, 2007

May 8, 2007

> I'd like to suggest that we remove all (or nearly all) uses of > xrange from the stdlib. A quick scan shows that most of the usage > of it is unnecessary. With it going away in 3.0, and it being > informally deprecated anyway, it seems like a good thing to go away > where possible. > >Any objections? -1 It isn't "informally deprecated". The xrange() builtin has different performance characteristics and is still needed in Py2.x. Only in Py3k where range() becomes … [View More]

1 0

Commit Keys
by Calvin Spealman May 7, 2007

May 7, 2007

I lost the key I originally gave for commiting my summaries. Who do I talk to about fixing that? -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/

3 2

Re: [Python-Dev] Pre-pre PEP for 'super' keyword
by Delaney, Timothy (Tim) May 6, 2007

May 6, 2007

Steve Holden wrote: > Tim Delaney wrote: >> BTW, one of my test cases involves multiple super calls in the same >> method - there is a *very* large performance improvement by >> instantiating it once. >> > And how does speed deteriorate for methods with no uses of super at > all (which will, I suspect, be in the majority)? Zero - in those cases, no super instance is instantiated. There is a small one-time cost when the class is constructed in the reference … [View More]

1 0

ImportError on no permission
by Georg Brandl May 6, 2007

May 6, 2007

Today, I got a request regarding importing semantics. When a module file cannot be opened because of, say, lacking read permission, the rest of sys.path will be tried, and if nothing else is found, you get "no module named foo". The reporter claimed, and I understand that, that this is a pain to debug and it would be good to at least add a better message to the import error. Now, why don't we change the semantics as follows: if a file with matching name exists (in import.c::find_module), but … [View More]

4 5

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser May 6, 2007

May 6, 2007

Patch / Bug Summary ___________________ Patches : 360 open ( +4) / 3760 closed ( +4) / 4120 total ( +8) Bugs : 971 open ( +3) / 6683 closed (+10) / 7654 total (+13) RFE : 257 open ( +3) / 282 closed ( +0) / 539 total ( +3) New / Reopened Patches ______________________ test_1686475 of test_os & pagefile.sys (2007-04-28) http://python.org/sf/1709112 opened by A.B., Khalid run test_1565150(test_os.py) only on NTFS (2007-04-29) http://python.org/sf/… [View More]

1 0

Summary of Tracker Issues
by Tracker May 6, 2007

May 6, 2007

ACTIVITY SUMMARY (04/29/07 - 05/06/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1650 open ( +1) / 8584 closed ( +0) / 10234 total ( +1) Average duration of open issues: 784 days. Median duration of open issues: 736 days. Open Issues Breakdown open 1650 ( +1) pending 0 ( +0) Issues Created Or Reopened (1) ______________________________ yahoo … [View More]

1 0

PyInt_AsSsize_t on x64
by Kristján Valur Jónsson May 5, 2007

May 5, 2007

Hello there. I'm working on getting the 64 bit build of the trunk pass the testsuite. Here is one snag, that you could help me fix. In test_getargs2(), there is at line 190: self.failUnlessEqual(99, getargs_n(Long())) Now, the Long class has a __int__ method which returns 99L. However, we run into trouble here: intobject.c:210 if ((nb = op->ob_type->tp_as_number) == NULL || (nb->nb_int == NULL && nb->nb_long == 0)) { PyErr_SetString(… [View More]

2 2

x64 and the testsuite
by Kristján Valur Jónsson May 5, 2007

May 5, 2007

Hello again. A lot of overflow tests fail in the testsuite, by expecting overflow using sys.maxint. for example this line, 196, in test_index.py: self.assertEqual(x[self.neg:self.pos], (-1, maxint)) At the moment, I am disabling these tests with if "64 bit" not in sys.version: So, two questions: Should we add something like sys.maxsize to keep these overflow tests valid? Also, some tests just kill the computer when given large values, that are expected to overflow. Sometimes it would be … [View More]

5 5

updated PEP3125, Remove Backslash Continuation
by Jim Jewett May 4, 2007

May 4, 2007

Major rewrite. The inside-a-string continuation is separated from the general continuation. The alternatives section is expaned to als list Andrew Koenig's improved inside-expressions variant, since that is a real contender. If anyone feels I haven't acknowledged their concerns, please tell me. -------------- PEP: 3125 Title: Remove Backslash Continuation Version: $Revision$ Last-Modified: $Date$ Author: Jim J. Jewett <JimJJewett(a)gmail.com> Status: Draft Type: Standards Track … [View More]Content-Type: text/x-rst Created: 29-Apr-2007 Post-History: 29-Apr-2007, 30-Apr-2007, 04-May-2007 Abstract ======== Python initially inherited its parsing from C. While this has been generally useful, there are some remnants which have been less useful for python, and should be eliminated. This PEP proposes elimination of terminal ``\`` as a marker for line continuation. Motivation ========== One goal for Python 3000 should be to simplify the language by removing unnecessary or duplicated features. There are currently several ways to indicate that a logical line is continued on the following physical line. The other continuation methods are easily explained as a logical consequence of the semantics they provide; ``\`` is simply an escape character that needs to be memorized. Existing Line Continuation Methods ================================== Parenthetical Expression - ([{}]) --------------------------------- Open a parenthetical expression. It doesn't matter whether people view the "line" as continuing; they do immediately recognize that the expression needs to be closed before the statement can end. An examples using each of (), [], and {}:: def fn(long_argname1, long_argname2): settings = {"background": "random noise" "volume": "barely audible"} restrictions = ["Warrantee void if used", "Notice must be recieved by yesterday" "Not responsible for sales pitch"] Note that it is always possible to parenthesize an expression, but it can seem odd to parenthesize an expression that needs them only for the line break:: assert val>4, ( "val is too small") Triple-Quoted Strings --------------------- Open a triple-quoted string; again, people recognize that the string needs to finish before the next statement starts. banner_message = """ Satisfaction Guaranteed, or DOUBLE YOUR MONEY BACK!!! some minor restrictions apply""" Terminal ``\`` in the general case ---------------------------------- A terminal ``\`` indicates that the logical line is continued on the following physical line (after whitespace). There are no particular semantics associated with this. This form is never required, although it may look better (particularly for people with a C language background) in some cases:: >>> assert val>4, \ "val is too small" Also note that the ``\`` must be the final character in the line. If your editor navigation can add whitespace to the end of a line, that invisible change will alter the semantics of the program. Fortunately, the typical result is only a syntax error, rather than a runtime bug:: >>> assert val>4, \ "val is too small" SyntaxError: unexpected character after line continuation character This PEP proposes to eliminate this redundant and potentially confusing alternative. Terminal ``\`` within a string ------------------------------ A terminal ``\`` within a single-quoted string, at the end of the line. This is arguably a special case of the terminal ``\``, but it is a special case that may be worth keeping. >>> "abd\ def" 'abd def' + Many of the objections to removing ``\`` termination were really just objections to removing it within literal strings; several people clarified that they want to keep this literal-string usage, but don't mind losing the general case. + The use of ``\`` for an escape character within strings is well known. - But note that this particular usage is odd, because the escaped character (the newline) is invisible, and the special treatment is to delete the character. That said, the ``\`` of ``\(newline)`` is still an escape which changes the meaning of the following character. Alternate Proposals =================== Several people have suggested alternative ways of marking the line end. Most of these were rejected for not actually simplifying things. The one exception was to let any unfished expression signify a line continuation, possibly in conjunction with increased indentation. This is attractive because it is a generalization of the rule for parentheses. The initial objections to this were: - The amount of whitespace may be contentious; expression continuation should not be confused with opening a new suite. - The "expression continuation" markers are not as clearly marked in Python as the grouping punctuation "(), [], {}" marks are:: # Plus needs another operand, so the line continues "abc" + "def" # String ends an expression, so the line does not # not continue. The next line is a syntax error because # unary plus does not apply to strings. "abc" + "def" - Guido objected for technical reasons. [#dedent]_ The most obvious implementation would require allowing INDENT or DEDENT tokens anywhere, or at least in a widely expanded (and ill-defined) set of locations. While this is concern only for the internal parsing mechanism (rather than for users), it would be a major new source of complexity. Andrew Koenig then pointed out [#lexical]_ a better implementation strategy, and said that it had worked quite well in other languages. [#snocone]_ The improved suggestion boiled down to:: The whitespace that follows an (operator or) open bracket or parenthesis can include newline characters. It would be implemented at a very low lexical level -- even before the decision is made to turn a newline followed by spaces into an INDENT or DEDENT token. There is still some concern that it could mask bugs, as in this example [#guidobughide]_:: # Used to be y+1, the 1 got dropped. Syntax Error (today) # would become nonsense. x = y+ f(x) Requiring that the continuation be indented more than the initial line would add both safety and complexity. Open Issues =========== + Should ``\``-continuation be removed even inside strings? + Should the continuation markers be expanced from just ([{}]) to include lines ending with an operator? + As a safety measure, should the continuation line be required to be more indented than the initial line? References ========== .. [#dedent] (email subject) PEP 30XZ: Simplified Parsing, van Rossum http://mail.python.org/pipermail/python-3000/2007-April/007063.html .. [#lexical] (email subject) PEP-3125 -- remove backslash continuation, Koenig http://mail.python.org/pipermail/python-3000/2007-May/007237.html .. [#snocone] The Snocone Programming Language, Koenig http://www.snobol4.com/report.htm .. [#guidobughide] (email subject) PEP-3125 -- remove backslash continuation, van Rossum http://mail.python.org/pipermail/python-3000/2007-May/007244.html Copyright ========= This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: [View Less]

1 0

Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword
by Delaney, Timothy (Tim) May 4, 2007

May 4, 2007

Guido van Rossum wrote: >> 1. When a method is defined, the class is bound to it via an attribute >> (which in my version is called func_class). > In Py3k all the func_XXX attrs are renamed __XXX__, so this would be > __class__; but that's a name reserved for something else, so it would > need to be something else. E.g. __containing_class__. Yep - I've just used a placeholder name. > Also, this would have to be done when the class is defined; when the > method is … [View More]being defined the class doesn't exist yet. Good point. Change that to "at the first opportunity" ;) >> 2. Every non-static method has an implicit cell variable called >> 'super'. > > I think you're using 'cell' in a different sense than it is normally > used in Python's implementation. What you are looking for is called a > local variable (I deduce this from your initialization of the "cell" > with something computed from the first argument). Actually, I think I'm using the terminology correctly - I'm talking about an entry in co_cellvars. Given the following class: class A(object): def f(self): super = super_factory() def inner(): return 'A' + super.f() print inner() the use of 'super' in both A.f and A.f.inner will produce an entry in A.f.func_code.co_cellvars and A.f.inner.func_code.co_freevars. What I'm proposing is that the `super = super_factory()` line be implicit in this case, resulting in the following code behaving identically: class A(object): def f(self): def inner(): return 'A' + super.f() print inner() >> The issue of super() vs. super.__call__() ambiguity - I'll need to >> look at that when I get home. > > Sounds irrelevant -- if super is equivalent to > __builtin__.__super__(<class>, <firstarg>) then super never gets > called; the only thing ever done to it (in the normal course of > things) is to request an attribute of it. Sorry - this is related to my proposal that the following two bits of code behave the same: class A(object): def f(self, *p, **kw): super.f(*p, **kw) class A(object): def f(self, *p, **kw): super(*p, **kw) But as has been pointed out, this creates an ambiguity with: class A(object): def f(self, *p, **kw): super.__call__(*p, **kw) so I want to see if I can resolve it. > super(ThisClass).method(...) # ??? > > The third exists so that you can create an "unbound" super instance > which is useful for the oft-misunderstood autosuper example in my > "descrintro" essay: > http://www.python.org/download/releases/2.2.3/descrintro/#metaclass_exam ples > . > > But since the latter is the hack that we're trying to replace with a > proper implementation here, I suspect we can get away with only > supporting the first two forms (and the third form is still supported > using __builtin__.__super__). Yep - that's my thought as well. I think it would be very rare to need super(ThisClass), although it makes some sense that that would be what super means in a static method ... Tim Delaney [View Less]

6 7

Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword
by Jim Jewett May 4, 2007

May 4, 2007

On 4/29/07, Tim Delaney <tcdelaney(a)optusnet.com.au> wrote: > I've been intending to write up a PEP for fixing super, but I haven't had > time to get to it. Calvin Spealman has the most recent draft. I hope he will incorporate this into his draft. > 1. 'super' becomes a keyword, that returns a super object for the instance > method currently being executed. So it is a "keyword" in the sense that None is a keyword; not in the stronger sense that "if" is a keyword? > 4. … [View More]

5 7