[Python-Dev] Exposing socket and poll objects in the Concrete Object Layer

[Michael Hudson]

Michel Pelletier <michel at dialnetwork.com> writes:

> On Thursday 14 August 2003 07:29, Michael Hudson wrote:
>>
>> Hmm.  I think it would be best to implement these in a CObject-y
>> style, like the way cPickle uses StringIO and the way (I presume,
>> haven't actually looked) _socket uses _ssl.
>
> Ooohhhh I didn't know about CObject until you mentioned it.  This is clearly 
> the way to go (still ugly, but at least endorsed).

And the ugliness can largely be hidden in the implementation, too.

> Something in the docs caught my eye:
>
> Doc/html/ext/using-cobjects.html
>
> "At first sight this [providing extension module services to other extension 
> modules] seems easy: just write the functions (without declaring them static, 
> of course), provide an appropriate header file, and document the C API. And 
> in fact this would work if all extension modules were always linked 
> statically with the Python interpreter. When modules are used as shared 
> libraries, however, the symbols defined in one module may not be visible to 
> another module. The details of visibility depend on the operating system; 
> ..."
>
> Are socketmodule and selectmodule always linked staticly with the Python 
> interpreter? 

$ ls build/lib.linux-i686-2.4/_socket.so 
build/lib.linux-i686-2.4/_socket.so

Doesn't look like it :-)

Cheers,
mwh

-- 
  > So what does "abc" / "ab" equal?
  cheese
         -- Steve Holden defends obscure semantics on comp.lang.python