[Python-Dev] UUID module
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.
>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
More information about the Python-Dev