Re: [Python-Dev] Summary of Tracker Issues
> I clicked on the tracker link out of curiosity noticed that the > tracker has been spammed -- issues 1028, 1029 and 1030 are all spam > (1028 seems a test by the spammer). > > These issues should be deleted and their creator's accounts disabled. (Notice that the spammer hasn't been as successful as he thinks - the spam downloads as plain text, not as HTML as he had hoped). That's actually an issue that will like require continuous volunteer efforts. Unless an automated spam filtering materializes (which may or may not happen), people will need to clean out spam manually. It's not that easy for a spammer to submit the spam: we require a registration with an email roundtrip - which used to be sufficient, but isn't anymore, as the spammers now have email accounts which they use for signing up. We have some machinery to detect spambots performing registration, and that already filters out a lot attempts (at least the spam frequency went down when this got activated), but some spammers get still past it. Now it's up to volunteers to do ongoing spam clearing, and we don't have that much volunteers. I think a single-click button "Spammer" should allow committers to lock an account and hide all messages and files that he sent, but that still requires somebody to implement it. Regards, Martin ___ 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
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
On 2007-05-12 02:42, Andrew McNabb wrote: > On Sat, May 12, 2007 at 01:30:52AM +0200, M.-A. Lemburg wrote: >> I wonder how we managed to survive all these years with >> the existing consistent and concise definition of the >> raw-unicode-escape codec ;-) >> >> There are two options: >> >> * no one really uses Unicode raw strings nowadays >> >> * none of the existing users has ever stumbled across the >>"problem case" that triggered all this >> >> Both ways, we're discussing a non-issue. > > > Sure, it's a non-issue for Python 2.x. However, when Python 3 comes > along, and all strings are Unicode, there will likely be a lot more > users stumbling into the problem case. In the first case, changing the codec won't affect much code when ported to Py3k. In the second case, a change to the codec is not necessary. Please also consider the following: * without the Unicode escapes, the only way to put non-ASCII code points into a raw Unicode string is via a source code encoding of say UTF-8 or UTF-16, pretty much defeating the original requirement of writing ASCII code only * non-ASCII code points in text are not uncommon, they occur in most European scripts, all Asian scripts, many scientific texts and in also texts meant for the web (just have a look at the HTML entities, or think of Word exports using quotes) * adding Unicode escapes to the re module will break code already using "...\u..." in the regular expressions for other purposes; writing conversion tools that detect this usage is going to be hard * OTOH, writing conversion tools that simply work on string literals in general is easy Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 13 2007) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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
[Python-Dev] generators and with
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
___
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
Re: [Python-Dev] generators and with
On Sun, May 13, 2007 at 04:56:15PM +0200, tomer filiba wrote:
>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
A better example may help to make your case. Would this do?
with mygeneratorfn() as g:
x = get_datum()
while g.send(x):
x = get_next(x)
The idea then is that you can't just use a 'for' loop (which will call
close() itself, IIRC) because you want access to the generator itself,
not just the return values from g.next().
I wouldn't have a problem with this proposal, but I consider the snippet
above to be fairly obscure Python already; the requirement to call
g.close() is not a great burden on someone capable of using g.send() et
al.
Dustin
___
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
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
> * without the Unicode escapes, the only way to put non-ASCII > code points into a raw Unicode string is via a source code encoding > of say UTF-8 or UTF-16, pretty much defeating the original > requirement of writing ASCII code only That's no problem, though - just don't put the Unicode character into a raw string. Use plain strings if you have a need to include Unicode characters, and are not willing to leave ASCII. For Python 3, the default source encoding is UTF-8, so it is much easier to use non-ASCII characters in the source code. The original requirement may not be as strong anymore as it used to be. > * non-ASCII code points in text are not uncommon, they occur > in most European scripts, all Asian scripts, > many scientific texts and in also texts meant for the web > (just have a look at the HTML entities, or think of Word > exports using quotes) And you are seriously telling me that people who commonly use non-ASCII code points in their source code are willing to refer to them by Unicode ordinal number (which, of course, they all know by heart, from 1 to 65536)? > * adding Unicode escapes to the re module will break code > already using "...\u..." in the regular expressions for > other purposes; writing conversion tools that detect this > usage is going to be hard It's unlikely to occur in code today - \u just means the same as u (so \u1234 matches u1234); if you want a backslash followed by u in your regular expression, you should write \\u. It would be possible to future-warn about \u in 2.6, catching these cases. Authors then would either have to remove the backslash, or duplicate it, depending on what they want to express. Regards, Martin ___ 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
Re: [Python-Dev] generators and with
"tomer filiba" <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> 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")
>
You can already ensure that the close() method is called quite easily:
with contextlib.closing(mygenerator()) as g:
g.next()
bar = g.send("foo")
___
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
Re: [Python-Dev] Summary of Tracker Issues
On 5/13/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Now it's up to volunteers to do ongoing spam clearing, and we don't > have that much volunteers. I think a single-click button "Spammer" > should allow committers to lock an account and hide all messages > and files that he sent, but that still requires somebody to implement > it. I'd expect that to be pretty effective -- like graffiti artists, spammers want their work to be seen, and a site that quickly removes them will not be worth the effort for them. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Draft PEP: Maintenance of Python Releases
> I don't understand the point of a "security release" made up to a year > after commit, especially in view of the first quoted paragraph. The objective is to reduce load for the release manager. Any kind of release that is worth anything takes several hours to produce, in my experience (if it could be made completely automatic, it wouldn't be good, since glitches would not be detected). I would like get Anthony's opinion on this aspect. > A > commit may not be made without confirming *immediate* releasability. > Isn't that the painful part of a release? If so, shouldn't an > immediate release should be made, and not be that much burden? (At > least in my practice, all that's left is an announcement -- which is > going to be about 2 lines of boilerplate, since detailed explanations > are prohibited -- and rolling tarballs.) See PEP 101. A release involves many more steps, and it's not clear whether a release candidate could be skipped. I think we would need to restrict the total number of releases made per year. The one-year limit may be debatable, and immediate releases might be possible, as long as there is some provision that releases are not made at a too-high rate. > If rolling tarballs etc is considered a burden, a "tag release" could > be made. OS distributors are going to import into a vendor branch > anyway, what they want is python-dev's certification that it's been > checked and (as much as possible given the urgency of a security > patch) is safe to apply to their package trees. I think OS distributors typically *do* use official tar balls, even if they import them as a vendor branch somewhere. Also, creating the tar ball is not the only activity: creating a new web page on pydotorg, running the test suite, etc. all is still necessary. In any case, the patch gets certified by being committed (with the indication that it is a security fix), so if they want certified patches, they can just import the maintenance branch. Regards, Martin ___ 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
[Python-Dev] Strange behaviour with PyEval_EvalCode
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, 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 );
Re: [Python-Dev] Strange behaviour with PyEval_EvalCode
On Sun, May 13, 2007, Joe Eagar wrote: > > 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. python-dev is probably not the best place to discuss this -- python-dev is primarily for discussions of *future* versions of Python. You would probably get better resuts posting to comp.lang.python. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Look, it's your affair if you want to play with five people, but don't go calling it doubles." --John Cleese anticipates Usenet ___ 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
Re: [Python-Dev] Draft PEP: Maintenance of Python Releases
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] |> I don't understand the point of a "security release" made up to a year | > after commit, especially in view of the first quoted paragraph. A security release is presumably a response to a serious problem. | I think we would need to restrict the total number of releases | made per year. The one-year limit may be debatable, and immediate | releases might be possible, as long as there is some provision | that releases are not made at a too-high rate. I would agree, but... has there been more that the one security release that I know about? tjr ___ 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
Re: [Python-Dev] Strange behaviour with PyEval_EvalCode
"Joe Eagar" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | why isn't PyEval_EvalCode documented anywhere? Most likely just overlooked and never reported. See Appendix A of the Python/C API http://docs.python.org/api/reporting-bugs.html If you make a report, please provide a link to the page where you think an entry should best go and, if you have figured it out, a draft entry. (plain text, no markup needed). For the rest, see Aahz's post. tjr ___ 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
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
On 2007-05-13 18:04, Martin v. Löwis wrote: >> * without the Unicode escapes, the only way to put non-ASCII >> code points into a raw Unicode string is via a source code encoding >> of say UTF-8 or UTF-16, pretty much defeating the original >> requirement of writing ASCII code only > > That's no problem, though - just don't put the Unicode character > into a raw string. Use plain strings if you have a need to include > Unicode characters, and are not willing to leave ASCII. > > For Python 3, the default source encoding is UTF-8, so it is > much easier to use non-ASCII characters in the source code. > The original requirement may not be as strong anymore as it > used to be. You can do that today: Just put the "# coding: utf-8" marker at the top of the file. However, in some cases, your editor may not be capable of displaying or letting you enter the Unicode text you have in mind. In other cases, there may be a corporate coding standard in place that prohibits using non-ASCII text in source code, or fixes the encoding to e.g. Latin-1. In all those cases, it's necessary to be able to enter the Unicode code points which do cannot be used in the source code using other means and the easiest way to do this is by using Unicode escapes. >> * non-ASCII code points in text are not uncommon, they occur >> in most European scripts, all Asian scripts, >> many scientific texts and in also texts meant for the web >> (just have a look at the HTML entities, or think of Word >> exports using quotes) > > And you are seriously telling me that people who commonly > use non-ASCII code points in their source code are willing > to refer to them by Unicode ordinal number (which, of course, > they all know by heart, from 1 to 65536)? No, I'm not. I'm saying that non-ASCII code points are in common use and (together with the above bullet) that there are situations where you can't put the relevant code point directly into your source code. Using Unicode escapes for these will always be a cludge, but it's still better than not being able to enter the code points at all. >> * adding Unicode escapes to the re module will break code >> already using "...\u..." in the regular expressions for >> other purposes; writing conversion tools that detect this >> usage is going to be hard > > It's unlikely to occur in code today - \u just means the same > as u (so \u1234 matches u1234); if you want a backslash > followed by u in your regular expression, you should write > \\u. > > It would be possible to future-warn about \u in 2.6, catching > these cases. Authors then would either have to remove the > backslash, or duplicate it, depending on what they want to > express. Good idea. The re module would then have to implement the same escaping scheme as the raw-unicode-escape code (only an odd number of backslashes causes the escaping code to trigger). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 13 2007) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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
[Python-Dev] Strange behaviour with PyEval_EvalCode
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, 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");
Re: [Python-Dev] Strange behaviour with PyEval_EvalCode
Joe Eagar wrote: > 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. > > Eh sorry about the double post. Joe ___ 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
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 362 open ( +2) / 3766 closed ( +6) / 4128 total ( +8) Bugs: 968 open ( -3) / 6692 closed ( +9) / 7660 total ( +6) RFE : 256 open ( -1) / 286 closed ( +4) / 542 total ( +3) New / Reopened Patches __ Fix off-by-one error in Modules/socketmodule.c (2007-05-06) CLOSED http://python.org/sf/1713797 opened by Bryan Østergaard Patch for PEP 3109 (2007-05-06) http://python.org/sf/1713889 opened by wpy os.linesep needs clarification (2007-05-07) CLOSED http://python.org/sf/1714700 opened by Gabriel Genellina x64 clean compile patch for _ctypes (2007-05-09) http://python.org/sf/1715718 opened by Kristján Valur "Really print?" Dialog (2007-05-11) http://python.org/sf/1717170 opened by Tal Einat textView code cleanup (2007-05-13) http://python.org/sf/1718043 opened by Tal Einat PEP 3123 implementation (2007-05-13) http://python.org/sf/1718153 opened by Martin v. Löwis Patches Closed __ Fix off-by-one error in Modules/socketmodule.c (2007-05-06) http://python.org/sf/1713797 closed by gbrandl make range be xrange (2006-04-18) http://python.org/sf/1472639 closed by nnorwitz xrange that supports longs, etc (2006-08-24) http://python.org/sf/1546078 closed by nnorwitz os.linesep needs clarification (2007-05-08) http://python.org/sf/1714700 closed by gbrandl PEP 3132: extended unpacking (2007-05-02) http://python.org/sf/1711529 closed by gbrandl Bastion and rexec message out-of-date (2007-04-12) http://python.org/sf/1698951 closed by gbrandl New / Reopened Bugs ___ smtplib starttls() didn't do TLS Close Notify when quit() (2007-05-07) CLOSED http://python.org/sf/1713993 opened by AndCycle Multiple re.compile flags cause error (2007-05-06) CLOSED http://python.org/sf/1713999 opened by Saul Spatz character set in Japanese on Ubuntu distribution (2007-05-04) http://python.org/sf/1713252 reopened by cgrell Universal line ending mode duplicates all line endings (2007-05-07) CLOSED http://python.org/sf/1714381 opened by Geoffrey Bache subprocess.py problems errors when calling cmd.exe (2007-05-07) http://python.org/sf/1714451 opened by tzellman python throws an error when unpacking bz2 file (2007-05-08) http://python.org/sf/1714773 opened by runnig datetime.date won't accept 08 or 09 as valid days. (2007-05-08) CLOSED http://python.org/sf/1715302 opened by Erik Wickstrom Const(None) in compiler.ast.Return.value (2007-05-09) http://python.org/sf/1715581 opened by Ali Gholami Rudi Destructor behavior faulty (2007-05-12) http://python.org/sf/1717900 opened by Wolf Rogner posixpath and friends have uses that should be documented (2007-05-13) http://python.org/sf/1718017 opened by Gabriel de Perthuis Bugs Closed ___ smtplib starttls() didn't do TLS Close Notify when quit() (2007-05-07) http://python.org/sf/1713993 deleted by andcycle Multiple re.compile flags cause error (2007-05-07) http://python.org/sf/1713999 closed by gbrandl Universal line ending mode duplicates all line endings (2007-05-07) http://python.org/sf/1714381 closed by gbrandl datetime.date won't accept 08 or 09 as valid days. (2007-05-08) http://python.org/sf/1715302 closed by fdrake Segfaults on memory error (2007-04-10) http://python.org/sf/1697916 closed by gbrandl types.InstanceType is missing but used by pydoc (2007-04-10) http://python.org/sf/1697782 closed by gbrandl improving distutils swig support - documentation (2004-10-14) http://python.org/sf/1046945 closed by gbrandl New / Reopened RFE __ Expose callback API in readline module (2007-05-06) http://python.org/sf/1713877 opened by strank if something as x: (2007-05-07) http://python.org/sf/1714448 opened by k0wax RFE Closed __ commands module (2007-05-06) http://python.org/sf/1713624 closed by gbrandl additions to commands lib (2003-11-11) http://python.org/sf/840034 closed by gbrandl A large block of commands after an "if" cannot be (2003-03-28) http://python.org/sf/711268 closed by gbrandl Please add .bz2 in encodings_map (in the module mimetypes) (2007-04-25) http://python.org/sf/1707693 closed by gbrandl ___ 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
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
M.-A. Lemburg wrote: > * non-ASCII code points in text are not uncommon, they occur > in most European scripts, all Asian scripts, In an Asian script, almost every character is likely to be non-ascii, which is going to be pretty hard to read as a string of unicode escapes. Maybe what we want is a new kind of string literal in which *everything* is a unicode escape. A sufficiently smart editor could then display it using the appropriate characters, yet it could still be dealt with as ascii- only in a pinch. -- Greg ___ 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
Re: [Python-Dev] Summary of Tracker Issues
>> Now it's up to volunteers to do ongoing spam clearing, and we don't >> have that much volunteers. I think a single-click button "Spammer" >> should allow committers to lock an account and hide all messages and >> files that he sent, but that still requires somebody to implement it. Guido> I'd expect that to be pretty effective -- like graffiti artists, Guido> spammers want their work to be seen, and a site that quickly Guido> removes them will not be worth the effort for them. I'm still (slowly) working on adding SpamBayes to Roundup. I've exchanged one or two messages with Richard Jones. In the meantime (thinking out loud here), would it be possible to keep search engines from seeing a submission or an edit until a trusted person has had a chance to approve it? It should also be possible for trusted users to mark other users as trusted. Trusted users' submissions and edits should not require approval. In a rather short period of time I think you'd settle on a fairly static group of trusted users who are responsible for most changes. Only new submissions from previously unknown users would require approval. Skip ___ 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
Re: [Python-Dev] Summary of Tracker Issues
> In the meantime (thinking out loud here), would it be possible to keep > search engines from seeing a submission or an edit until a trusted person > has had a chance to approve it? It would be possible, but I would strongly oppose it. A bug tracker where postings need to be approved is just unacceptable. Regards, Martin ___ 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
