static storage

static storage of the state of the generator is not implemented.Static storage is required to synchronize multiple threads or processes requesting UUIDs or to save the state of the generator during reboots.

This may have an effect in the following szenarios:

1. a process requesting more than one UUID/tick.This requires padding of the UUID and therefore some means to tell other processes about the current state of padding.

1. the systems clock has turned backwards. There is no information available to compare previous time or some initial time with the current time.

One problem is not having an IPC module at hand. mmap is fine to share memory, but python lacks system wide locks or semaphores to synchronize multiple processes. Unless this problem is solved in python there is no way I am aware off to get the static storage thing done. All these issues lower the quality of time based UUIDs slightly but is covered fully by the RFC 4122 spec.

randomness

the throw in replacement of random.getrandbits() for older python versions may or may not work as expected. I am an analphabet when it comes to randomness, so best thing I could do was google for an instant replacement (..)

others

A real chalenge is how to calculate resolution of what pythons time.time() returns. This affects szenario 1 but should not have any noticable side effects. The current implementation limits the number of UUIDs that can be generated / tick to 10.000