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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4