On Thursday 14 August 2003 07:29, Michael Hudson wrote: > > 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. Ooohhhh I didn't know about CObject until you mentioned it. This is clearly the way to go (still ugly, but at least endorsed). > > 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!" :-) It's a good argument. I guess it depends on the goals of the AOL and COL APis. Personally I think it would be worth the effort trying to make the APIs close to the same richness that Python provides. This is a huge advantage for Jython; Java programmers do not need to jump through CObject-like hoops to use other Java objects. CObject may not be painful enough to warrent the extra work (It doesn't seem incredibly painful). Something in the docs caught my eye: Doc/html/ext/using-cobjects.html "At first sight this [providing extension module services to other extension modules] seems easy: just write the functions (without declaring them static, of course), provide an appropriate header file, and document the C API. And in fact this would work if all extension modules were always linked statically with the Python interpreter. When modules are used as shared libraries, however, the symbols defined in one module may not be visible to another module. The details of visibility depend on the operating system; ..." Are socketmodule and selectmodule always linked staticly with the Python interpreter? If this is the case I think its good to do as the first part of this paragraph says, write the functions, provide a header file, and document the API. The COL will only get more functional. -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