[Python-Dev] Exposing socket and poll objects in the Concrete
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,
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.
More information about the Python-Dev