Michel Pelletier <michel at dialnetwork.com> writes:
> 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.
Is it that bad? You can wrap them up in utility functions & so on. I
agree it's a bit vulgar.
> 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?
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.
> 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.
I guess this is easy enough with CObjects.
> Does this sound useful to anyone else?
It falls into the "yep, might be handy" category, but I can't say that
*I* would find it intensely useful myself.
> 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!" :-)
Cheers,
mwh
--
M-x psych[TAB][RETURN]
-- try it
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