[Python-Dev] UUID module

Fredrik Lundh fredrik at pythonware.com
Fri Jun 9 10:11:14 CEST 2006

Ka-Ping Yee wrote:

> Quite a few people have expressed interest in having UUID
> functionality in the standard library, and previously on this
> list some suggested possibly using the uuid.py module i wrote:
>     http://zesty.ca/python/uuid.py


> This module provides a UUID class, functions for generating
> version 1, 3, 4, and 5 UUIDs, and can convert UUIDs to and from
> strings of 32 hex digits and strings of 16 bytes.
> The thread of messages posted on python-dev begins here:
>     http://mail.python.org/pipermail/python-dev/2006-March/062119.html
> My reading of this is that there was a pretty good consensus on
> the issues with this module that need to be addressed:
>     (a) UUIDs should be immutable (and usable as dict keys).
>     (b) The str() of a UUID should not contain curly braces.
>     (c) The uuid1() function, which generates a version-1 UUID,
>         uses a very slow method of getting the MAC address.
>     (d) The retrieved MAC address should be cached.
>     (e) Tests need to be written.

       (f) "import uuid" or "import uuidlib" ?

> The big question seems to be item (c); all the other items are easy
> to take care of.  Assuming (a), (b), (d), and (e) are done, i see a
> few options for how to proceed from there:
>     1.  Remove the uuid1() function, then put uuid.py in the
>         standard library so at least we'll have the rest of the
>         UUID functionality in 2.5b1.  Fill in uuid1() later.
>     2.  Remove the MAC-address functionality from uuid.py; instead
>         let the caller give the MAC address as an argument to uuid1().
>         Put that in the standard library for 2.5b1 and fill in the
>         function for retrieving the MAC address later.
>     3.  Add uuid.py to the standard library with its current slow
>         method of finding the MAC address (parsing the output of
>         ifconfig or ipconfig), but cache the output so it's only
>         slow the first time.
>     4.  Figure out how to use ctypes to retrieve the MAC address.
>         This would only work on certain platforms, but we could
>         probably cover the major ones.  On the other hand, it seems
>         unlikely that this would be fully hammered out before the
>         code freeze.
>     5.  Don't include any UUID functionality in 2.5b1; put it off
>         until 2.6.

       6.  Combine 2 and 3: require the user to pass in a MAC argument
           to uuid1, but provide a SlowGetMacAddress helper that wraps
           the existing code.


More information about the Python-Dev mailing list