I believe Starlette needs a feature like Flask’s request.values.

[PowerWordTree]

I believe Starlette needs a feature like Flask’s request.values.
It doesn’t seem particularly difficult to implement, and it would make handling use cases that aren’t covered by OpenAPI annotations much more convenient.

async def parse_params(request: Request) -> dict[str, Any]:
    result = {}

    await request.body()
    with contextlib.suppress(Exception):
        query_params = request.query_params
        for name in query_params.keys():
            param = query_params.getlist(name)
            result[name] = param[0] if len(param) == 1 else param

        content_type = request.headers.get("content-type", "").lower()
        if FORM_ENCODE in content_type or FORM_MULTI in content_type:
            form_params = await request.form()
            for name in form_params.keys():
                param = form_params.getlist(name)
                result[name] = param[0] if len(param) == 1 else param
        elif APP_JSON in content_type:
            json_params = await request.json()
            if isinstance(json_params, dict):
                result.update(json_params)

    return result

[Kludex]

What does the request.values do?

[PowerWordTree]

Flask’s request.values merges request.args and request.form into a single dict-like interface. It’s useful when you want to access parameters without caring whether they came from the query string or a form submission. It prioritizes form data over args, and doesn’t include JSON payloads. I think Starlette could benefit from a similar helper, especially for routes that don’t use OpenAPI or strict schema validation.
Starlette’s request object already has a .values() method, but it comes from the Mapping[str, Any] interface inherited via HTTPConnection. This method returns the values of the internal mapping (i.e., .values() from a dict), not request parameters. That can be misleading, especially for developers coming from Flask who expect request.values to give them query/form parameters. So not only is the unified parameter access missing, but the existing .values() method might cause confusion due to naming overlap.

[Kludex]

I think adding this feature would actually cause more confusion to the current users than the confusion you mention.