Re: Iterating generator from C
Christian Tismer
> Hi,
>
>
> I am working on project that has embedded python interpreter to run
> user-specified python procedures. Those procedures might return any
> iterable object with set of result data -- basically everything for which
> iter() returns valid object (list, tuple, dict, iterator etc)
>
> It works ok, except generator under Python 2.4 with debugging enabled (see
> http://sourceforge.net/tracker/index.php?func=detail&aid=1483133&group_id=5470&atid=105470).
>
> Is there any way to rewrite following program to handle returned generator
> without hitting this bug?
I found this bug as well, and I think the fix should be
back-ported.
This problem can only show up when you are comiling a C
extension, anyway.
Why don't you just apply the fix and compile your own?
It is just a wrong assertion, anyway.
ciao - chris
--
Christian Tismer :^) <mailto:tis...@stackless.com>
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
Sven Suursoho
>> I am working on project that has embedded python interpreter to run
>> user-specified python procedures. Those procedures might return any
>> iterable object with set of result data -- basically everything for
>> which iter() returns valid object (list, tuple, dict, iterator etc)
>> It works ok, except generator under Python 2.4 with debugging enabled
>> (see
>> http://sourceforge.net/tracker/index.php?func=detail&aid=1483133&group_id=5470&atid=105470).
>> Is there any way to rewrite following program to handle returned
>> generator without hitting this bug?
>
> I found this bug as well, and I think the fix should be
> back-ported.
> This problem can only show up when you are comiling a C
> extension, anyway.
> Why don't you just apply the fix and compile your own?
> It is just a wrong assertion, anyway.
Unfortunately, this is not an option because I can't control used
environment: I'm trying to improve PostgreSQL's stored procedure language
PL/Python and this software can be used everywhere.
At first I tried to block using generators if Py_DEBUG is defined. But
this wouldn't work because of another, overlapping bug in Fedora Core 4's
RPM packaging system (didn't check other versions) -- it disables Py_DEBUG
but strips -DNDEBUG from compiler's command-line i.e. no Py_DEBUG and
still active asserts().
See:
http://archives.postgresql.org/pgsql-patches/2006-05/msg00042.php
http://archives.postgresql.org/pgsql-patches/2006-05/msg00105.php
--
Sven Suursoho
Christian Tismer
>>> Is there any way to rewrite following program to handle returned
>>> generator without hitting this bug?
The only way I can think of getting around this is to make
sure that there is always a running python frame.
This would be possible if you can control how the
extension is called.
> Unfortunately, this is not an option because I can't control used
> environment: I'm trying to improve PostgreSQL's stored procedure
> language PL/Python and this software can be used everywhere.
Then there is no other way than to report the bug, get the
fix back-ported and nagging the PL/Python maintainers
to update things after the fix.
Also a test should be added which is probably missing since a while.
I'd put a warning somewhere that generators are broken in
debug mode, file an issue as well, but avoid trying to hack
around this. It would make the bug even more resistent :-)