Tal Einat added the comment:
I too find this surprising, especially given how thoroughly UUID validates
inputs of types other than "hex".
The documentation simply states that for hex input, hypens, curly braces and a
URN prefix are optional. In practice, though, it is much more lenient than
Windson Yang added the comment:
> Maybe a line should be added in the documentation to prevent people using
> this as a validator without more check?
I don't expect uuid.UUID could be used as a validator myself, but I agreed we
can warn users in the documentation if lots of them confuse abou
Cédric Cabessa added the comment:
> Is there are reason your validator doesn't use uuid.UUID to normalize the
> value? That is, whatever the customer provides, why not use the result of
> stringifying the resulting UUID
Yes, this is exactly what we do now
However this behaviour is a bit surp
Josh Rosenberg added the comment:
The documentation does describe a fairly flexible parser. Perhaps it's a little
too flexible on stuff like URN prefixes, but I don't think we could start
enforcing a stricter class of hyphen separations without potentially breaking
existing code.
Is there a
New submission from Cédric Cabessa :
UUID constructor accept string with too many dashes or keyword like urn: / uuid:
For eg, this code do not raise
```
>>> import uuid
>>> uuid.UUID('0be--468urn:urn:urn:urn:54-4bf9-41--d4-9697-41d735uuid:4fbe85uuid:')
UUID('0be46854-4bf9-41d4-9697-41d7
