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

[Michael Hudson]

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