[Python-Dev] uuid module - byte order issue (original) (raw)

Ka-Ping Yee python-dev at zesty.ca
Fri Aug 4 19:32:32 CEST 2006

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 clockseq 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

More information about the Python-Dev mailing list