Okay. I have done as Fredrik suggested: > 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.
I agree with Thomas Wouters: > That sounds like the right thing to do, although I wouldn't call it > "slow"; just let it be documented as 'might not always work and > might be inefficient', The method for getting the node ID is called getnode() and is documented as possibly slow. If a hardware address cannot be obtained, we use a random 48-bit number with the highest bit set to 1, as recommended by RFC 4122. I have done as Skip proposed here: > Or make the MAC address an optional arg to uuid1. If given, use it. > If not, use the slow lookup (then cache the result). I've made the address an optional argument, not a required one, because i think "Explicit better than implicit" applies to changes in output. It makes sense to require an explicit argument if it's actually going to produce a different result, but i don't think it is necessary to require an explicit argument just because the routine might be a bit slow. Letting the address be an optional argument means that in future, we can change the implementation of getnode() to make it faster or more reliable, and users of the module will benefit without having to change any of their code. Finally, Phillip brought up PEAK: > PEAK's uuid module does this such that if win32all is present, > you get a Windows GUID, or if you have a FreeBSD 5+ or > NetBSD 2+ kernel you use the local platform uuidgen API. See e.g.: ...so i looked at PEAK's getnodeid48() routine and borrowed the Win32 calls from there, with a comment giving attribution to PEAK. Oh, and there is now a test suite that should cover all the code paths. This is all posted at http://zesty.ca/python/uuid.py now, documentation page at http://zesty.ca/python/uuid.html, tests at http://zesty.ca/python/test_uuid.py . I'll sleep now (6 am), commit tomorrow unless there are objections. Thanks for your input, everyone! -- ?!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
