Home Original page

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

Michel Pelletier michel at dialnetwork.com
Wed Aug 13 10:02:16 EDT 2003 
I'm sketching a C module for a client using new style classes.  I'd like to 
use, and return to the user in some cases, Python socket and poll objects.  I 
want to create socket objects for custom connection handlers and poll objects 
to poll a set of handlers periodically; all written in C and intended to be 
subclassed in Python to customize behavior.  Unfortunately these objects 
cannot be created, as far as I can tell, in C without resorting to PyImport_* 
and PyObject_Call* hacks which are alarmingly ugly.

I could of course just use the standard socket and select C libraries, but 
this means re-implementing all the hacks that make the Python implementations 
so rock solid across platforms, and it also means I can't return socket and 
poll objects so that *Python* subclasses of my code, and other Python code, 
can use those objects directly.

It seems to me that socket and poll objects can be easily exposed to C 
programmers through the Concrete Object Layer API.  There may be a good 
reason why this isn't so that I don't see.  Does it makes sense to expose 
methods like PySocket_New, PySocket_Bind etc. and PyPoll_New, PyPoll_Poll, 
PyPoll_Register etc?

One reason I can see is that these modules cannot be guaranteed to work 
consistently (if at all) across all platforms.  In this case it is acceptable 
to my client to detect that condition and explicitly fail.  We do not ever 
anticipate using platforms upon which these services are broken.

Does this sound useful to anyone else?  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.

-Michel
More information about the Python-Dev mailing list