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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
