[Pythonmac-SIG] Restrictions on what you can do in a Python module?

Bob Ippolito bob at redivi.com
Wed Aug 27 15:20:37 EDT 2003


On Wednesday, Aug 27, 2003, at 14:02 America/New_York, Michael Hudson 
wrote:

> Robb Brown <brownr at ucalgary.ca> writes:
>
>> Hm.  Strange that the same code works from C but not Python... dcmtk
>> does apparently use some threads.
>
> Meep!  Here be dragons, at least possibly.

It's also not the same code, he could quite possibly be doing something 
wrong (either generically wrong, or not handling threadstates, the GIL, 
or callbacks correctly.. I think this bites a lot of people the first 
time they run into it) at the Python C API level.

Personally, I find Pyrex ( 
http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex ) to be extremely 
useful for writing C extensions (either wrappers or otherwise).  It 
does a *whole lot* of stuff for you that's quite a chore from the 
Python C API, and you get to write the code in (a slightly reduced in 
some respects, but extended in others to support C things like static 
types, typecasts, structures, etc) python syntax.  You do have to do a 
bit of text processing to wrap existing header files (most of which 
I've been able to do with regular expressions), but perhaps someone 
sometime can write something that automates this.

>> Do I have to do something specific to make C threads work with
>> Python?
>
> I don't think so.  But if the toolkit makes callbacks to your code,
> then things can get really entertaining.

http://www.python.org/doc/current/api/threads.html

>
>> Unfortunately, any threading is done within the toolkit - which I'd
>> rather not modify too much.  Is there something I put in the
>> wrapper?
>
> Can you show us a small example?  Even if there's noone here who
> understands the toolkit we might be able to spot some potential red
> flags.

That would help immensely.

-bob




More information about the Pythonmac-SIG mailing list