
At 11:16 AM 6/10/2006 -0500, Ka-Ping Yee wrote:
On Sat, 10 Jun 2006, Thomas Heller wrote:
[some nice ctypes code]
Done. Works like a charm. Thanks for providing the code!
On Sat, 10 Jun 2006, Phillip J. Eby wrote:
Also, for Python 2.5, these imports could probably be replaced with a ctypes call, though I'm not experienced enough w/ctypes to figure out what the call should be.
Happily, we have *the* ctypes guru here, and he's solved the problem for Windows at least.
Similarly, for the _uuidgen module, you've not included the C source for that module or the setup.py incantations to build it.
Yes, the idea was that even though _uuidgen isn't included with core Python, users would magically benefit if they installed it (or if they happen to be using Python in a distribution that includes it);
_uuidgen is actually peak.util._uuidgen; as far as I know, that's the only place you can get it.
it's the same idea with the stuff that refers to Win32 extensions. Is the presence of _uuidgen sufficiently rare that i should leave out uuidgen_getnode() for now, then?
Either that, or we could add the code in to build it. PEAK's setup.py does some relatively simple platform checks to determine whether you're on a BSD that has it. The other alternative is to ask the guru nicely if he'll provide another ctypes snippet to call the uuidgen(2) system call if present. :) By the way, I'd love to see a uuid.uuid() constructor that simply calls the platform-specific default UUID constructor (CoCreateGuid or uuidgen(2)), if available, before falling back to one of the Python implementations. Most of my UUID-using application code doesn't really care what type of UUID it gets, and if the platform has an efficient mechanism, it'd be convenient to use it.