On Thu, 3 Aug 2006, Oren Tirosh wrote:
> The UUID module uses network byte order, regardless of the platform
> byte order. On little-endian platforms like Windows the ".bytes"
> property of UUID objects is not compatible with the memory layout
RFC 4122 says:
In the absence of explicit application or presentation protocol
specification to the contrary, a UUID is encoded as a 128-bit
object, as follows:
The fields are encoded as 16 octets, with the sizes and order of
the fields defined above, and with each field encoded with the
Most Significant Byte first (known as network byte order).
> Ka-Ping Yee writes* that the Windows UUID generation calls are not RFC
> 4122 compliant and have an illegal version field.
[...]
> If the correct byte order is used the UUIDs generated by Windows XP
> are valid version 4 UUIDs:
I see. I stand corrected, then. My interpretation of RFC 4122 would
be that the uuid.py module currently completely implements RFC 4122;
while Windows XP can't be said to violate RFC 4122, supporting this
alternative byte order would be an optional feature.
> The bytes property and bytes argument to the constructor should use
> the platform byte order.
I disagree; i think the main interface to uuid.py should behave
consistently independent of the platform, and should conform to the
default encoding in RFC 4122. However, we could certainly consider
adding a 'bytes_le' field to support the functionality you describe.
I'll ask Anthony whether adding such a field would be permitted at
this stage of the release process.
> There is another issue with version 1 uuid generation:
> >>> len(set(uuid.uuid1() for i in range(1000)))
> 992
>
> The problem is that the random clock_seq field is only 14 bits long.
> If enough UUIDs are generated within the same system clock tick there
> will be collisions.
The clock field of the UUID has enough resolution to avoid collisions;
the problem you're describing is a limitation of the platform's clock,
not the UUID module. It doesn't happen on Mac OS X, for example.
> Suggested solution: use the high-resolution of the
> time field (100ns) to generate a monotonically increasing timestamp
> that advances at least by 1 for each call, when time.time() returns
> the same value on subsequent calls.
That sounds like a fine solution to me. I'll look into it.
-- ?!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
