Convert an uuid.UUID variable into int when pass it in params

[WeakX]

Please confirm the following

• I agree to follow the aio-libs Code of Conduct

• I have checked the current issues for duplicates.

• I understand this is open source software provided for free and that I might not receive a timely response.
• I am positive I am NOT reporting a (potential) security
  vulnerability, to the best of my knowledge. (These must be shared by
  submitting this report form instead, if
  any hesitation exists.)

• I am willing to submit a pull request with reporoducers as xfailing test cases or even entire fix. (Assign this issue to me.)

Describe the bug

I've defined a pydantic model (let's call it User) as the input model of my view function, which has a field annotated as uuid.UUID named user_id.

When I pass user.user_id as a part of params in a request(use aiohttp), yarl will convert the type of uuid.UUID into int before cast it into string.

For example: uuid.UUID('3199712f-1b78-4420-852b-a73ee09e6a8f') -> '65928888857327045292976149998723820175'

by this line: https://github.com/aio-libs/yarl/blob/master/yarl/_query.py#L35

So i've change my code to check every param in params if it's instance of uuid.UUID.

I came here to ask if this conversion behavior is as expected? Is there a better compatibility implementation?

To Reproduce

as description above

Expected behavior

as description above

Logs/tracebacks

no need

Python Version

$ python --version
3.11

multidict Version

$ python -m pip show multidict
6.1.0

propcache Version

$ python -m pip show propcache
0.2.1

yarl Version

$ python -m pip show yarl
1.18.3

OS

linux or macos

Additional context

No response

[webknjaz]

I came here to ask if this conversion behavior is as expected? Is there a better compatibility implementation?

This is sort of an undefined behavior. People keep coming in to ask to support their favorite type which we usually reject, but that time when people wanted some numpy ints (#945) we gave in and special-cased it but in a relatively generic manner: #1139.

In general, I'd be happier with not special-casing stuff. bool remains forbidden due to the ambiguity of the semantics that is typically end-user dependent, for example.

I'm honestly not sure how to best handle such cases in a sustainable way since people can keep creating objects that behave like integers and get surprised when they are processed like integers 🤷‍♂️

Perhaps, just documenting that anything integer-like is turned into an int would be a good middle ground, not sure. We don't have the ability to programmatically determine what the user wanted, unfortunately...

cc @bdraco do you have any opinions?