uuid(3|5) generation does not accept names which are not utf-8 decodable

[marla396]

From the documentation:

uuid.uuid3(namespace, name)
Generate a UUID based on the MD5 hash of a namespace identifier (which is a UUID) and a name (which is a string).

As far as I can tell from RFC4122, name being a string is not a requirement and therefore there are UUIDs which we cannot generate. Is this a bug or am I missing something from the RFC?

[yourlefthandman]

** Not a UUID expert here **
I'm not sure I understand the issue here. Since the input is a string, it can be any sequence of unicode letters. Therefore, I don't see any inputs which you are prevented from inserting.
Can you give an example of a name \ use case which you would like to give as an input and cannot?

When looking at the RFC examples-

For example, some name spaces are the domain name system, URLs, ISO Object IDs (OIDs), X.500 Distinguished Names (DNs), and reserved words in a programming language.

All examples can have a string equivilent.

[MonadChains]

Looking at the source code of the function:

cpython/Lib/uuid.py

Lines 704 to 711 in da49128

	def uuid3(namespace, name):
	"""Generate a UUID from the MD5 hash of a namespace UUID and a name."""
	from hashlib import md5
	digest = md5(
	namespace.bytes + bytes(name, "utf-8"),
	usedforsecurity=False
	).digest()
	return UUID(bytes=digest[:16], version=3)

If you need to pass a bytes object as name you can decode it into a UTF-8 string with bytes.decode.
Maybe the function could be modified to make it accept also bytes objects as the name argument.

[marla396]

Sorry for the confusion should have posted a better example. But as @MonadChains states, if name can not be represented as an UTF-8 string, we cannot create a uuid3 for that particular name.

We can with the current implementation for example create uuid3 with a namespace of arbitrary data. Seems reasonable that the same should apply to name

[yourlefthandman]

I think there may be an issue with the definitions here, since name needs to be a string (=unicode). You may mean that bytes may not represent utf-8 sequence.
In the case you are mentioning is name is a bytes sequence which cannot be decoded as utf-8? For example b'\xff'?
If so, you can decode the byte stream using a different encoding (such as latin1 - which will always work for bytes as far as I know) and that way you can ensure that you will have a relevant unicode string for the function. Does that solve your issue?

[tiran]

I don't see a specification of string in RFC 4122. That leads to the conclusion that the RFC treats string as a C string (bytes). IMHO it would be reasonable to support both str and bytes types for name here.

[marla396]

@yourlefthandman The problem isn't that it's not solvable, one could just overwrite the uuid3 function to do what you want, it's a matter of reporting a possible improvement.

[hauntsaninja]

Thanks, looks like this was completed