[Python-Dev] UUID module (original) (raw)

Phillip J. Eby pje at telecommunity.com
Sat Jun 10 18:39:29 CEST 2006

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 uuidgengetnode() 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.

More information about the Python-Dev mailing list