[Python-Dev] UUID module

[Phillip J. Eby]

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.