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.
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.
What are your thoughts on this?
Thanks!
-- ?!ng
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
