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

[Michel Pelletier]

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).

> > Now that new style classes make it possible for people to write
> > classes in C, I think it will become a much more common practice,
> > and that Python programmers moving "down" to C will expect to be
> > able to use services in C that they take for granted in Python.
>
> This would also please those people who try to sneak Python onto
> projects with cries of "it's just a library of useful C routines!" :-)

It's a good argument.  I guess it depends on the goals of the AOL and COL 
APis.  Personally I think it would be worth the effort trying to make the 
APIs close to the same richness that Python provides.  This is a huge 
advantage for Jython; Java programmers do not need to jump through 
CObject-like hoops to use other Java objects.  CObject may not be painful 
enough to warrent the extra work (It doesn't seem incredibly painful).

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?  If this is the case I think its good to do as the first part of 
this paragraph says, write the functions, provide a header file, and document 
the API.  The COL will only get more functional.

-Michel