[Python-Dev] Choosing a best practice solution for Python/extension modules

James Pye lists at jwp.name
Sun Feb 22 18:38:43 CET 2009


On Feb 21, 2009, at 2:17 PM, Brett Cannon wrote:
> The other approach is having pickle contain code known not to be  
> overridden by anyone, import _pypickle for stuff that may be  
> overridden, and then import _pickle for whatever is available. This  
> approach has the perk of using a standard practice for how to pull  
> in different implementation. But the drawback, thanks to how globals  
> are bound, is that any code pulled in from _pickle/_pypickle will  
> not be able to call into other optimized code; it's a take or leave  
> it once the call chain enters one of those modules as they will  
> always call the implementations in the module they originate from.


fwiw,

I believe this is the approach that I've been using when I'm faced  
with the need to optimize code, but still want to retain a pure-Python  
version. Thankfully, I haven't had a need for "implementation  
intersections"(well, it almost works. I think. ;) for access to common  
module globals as the optimizations tend to be simple transformations  
or isolated classes. However, if I were faced with the problem of  
needing some common global data/functionality, I'd probably put it in  
yet-another-module and just import it explicitly in each  
implementation. Sure, it seems like it might be annoying, but so is  
maintaining multiple implementations. ;)

Specifically:

pbuffer.py - The python implementation
buffer.c -> cbuffer.so - The c implementation
buffer.py - The "abstraction module", trying to import the contents of  
the fast one first.

And in my unittest:

if c_buffer_module is not None:
   class c_buffer(buffer_test, unittest.TestCase):
     bufferclass = c_buffer_module.pq_message_stream

class p_buffer(buffer_test, unittest.TestCase):
   bufferclass = p_buffer_module.pq_message_stream

Of course, "buffer_test" is not invoked because it's not a TestCase.


However, Aahz is probably right about this thread belonging elsewhere.?
Hrm, day old, maybe it's been moved already.. sigh. :)


More information about the Python-Dev mailing list