fix: produce standard Python repr style

[henryiii]

Promised follow to #175. Now the error messages produce standard output like Python, such as Field 'project.thing' got 'value'. By matching the built-in repr style, we can now use repr directly, which fixes the display when printout out a non-string, instead of things like "True", "13", "{}", etc. The confusing wrong type, expected string (got "2") messages are finally better. :)

As usual, while going over this, fixed minor things. In this case, an extra , in a error message.

[henryiii]

This is the removed extra comma

[dnicolodi]

I'm not trilled by this change. I think that double quotes look much nicer as delimiters (and incidentally, we use double quotes for strings in the codebase now, so someone must think likewise). But, most importantly, this requires the users of pyproject-metadata to adjust the quoting style in their error messages to be consistent.

The main reason for doing this, is indeed to produce error messages embedding values that are not strings. However, I argue that in these cases, the value is not the important information, but rather the type, thus these error messages should be reworded to provide the type, not the value. wrong type, expected string (got "2") and wrong type, expected string (got 2) are different only if the reader knows that in this contest strings are quoted, otherwise they are identical. However, wrong type, expected string (got int)` is fairly straightforward to interpret.

However, if we are going in the direction of integrating pyproject-metadata into packaging, maybe the error messages format should be made to match the one used in packaging (assuming packaging uses a consistent formatting for error message). What does packaging do?

[henryiii]

Python itself uses single quotes as delimiters. So the built-in error message will all be formatted like this:

>>> int("x")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: 'x'

As is packaging (and most other packages):

>>> packaging.version.Version("x")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/henryschreiner/git/software/python-pyproject-metadata/.venv/lib/python3.12/site-packages/packaging/version.py", line 202, in __init__
    raise InvalidVersion(f"Invalid version: '{version}'")
packaging.version.InvalidVersion: Invalid version: 'x'

Double quotes for strings makes this easier, since the single quotes can be embedded into the string naturally without escaping. Though when printing a variable, you can just use repr. I'd have written the above as f"Invalid version: {version!r}".

I do think printing the type for that specific case is a good idea, though.

[henryiii]

Showing the type isn't always better, I think. This message:

Field 'project.keywords' has an invalid type, expecting a list of strings (got [1])

Which is pretty clear, then would be:

Field 'project.keywords' has an invalid type, expecting a list of strings (got list)

I'll see if we can be more clever, though.

FYI, I'm not stuck on the project.x part of the message having single quotes. Maybe field names shouldn't match the repr values. There's some precedent for this; the path strings in the official error messages are double-quoted. So you'd get this:

Field "project.keywords" has an invalid type, expecting a list of strings (got 'some string')

Thoughts?

[henryiii]

Also backticks are an option (from @flying-sheep on Discord).