[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
+1!
> 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.
</F>
More information about the Python-Dev
mailing list