Peter Schutt

I've detailed my thoughts on the DTO naming and why it is like it is in this discord: https://discord.com/channels/919193495116337154/1227621024481411223/1228558632363364412 - you might like to read that.

Issue is that the logs emitted via structlog's loggers don't pass through the standard library logging. This is why they aren't filtered by the level set on the root logger...

I'm not enthusiastic about adding more pydantic specific handling in our core, and wonder if there's not a way we can better manage this type of thing with our plugin...

> > I'm not enthusiastic about adding more pydantic specific handling in our core, and wonder if there's not a way we can better manage this type of thing with...

I believe a dup of this: https://github.com/litestar-org/litestar/issues/3411

You are correct. As part of the 1.x to 2.x transition we removed a lot of the app parameters that allowed a union of types for this very reason. There...

> if AppConfig.response_headers was changed to list[ResponseHeader] and the conversion to this type happened inside Litestar.__init__, before InitPluginProtocol.on_app_init was called with the AppConfig, thus preserving the arguments to Litestar.__init__, then...

This shouldn't be hard to implement. We are already calling the exception handers from within an async context: https://github.com/litestar-org/litestar/blob/77b62a2e9a4776f9532b1e03f694790ac42da400/litestar/middleware/exceptions/middleware.py#L234 We would need to change the type of the exception handlers...

In flask's `url_for()` any of the kwargs that aren't matched to path params are appended to the url as query params. They also allow setting things like `_anchor=...`.

We have the option of trying to migrate to a pattern like this, which allows us to be specific about where the supplied components live in the url, and also...