[Python-Dev] Exposing socket and poll objects in the Concrete
michel at dialnetwork.com
Thu Aug 14 16:16:28 EDT 2003
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:
"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.
More information about the Python-Dev