Requests as MutableMapping about starlette HOT 4 CLOSED

No pressing need for this.

from starlette.

I have recently run into the need to hash requests, so I have two questions potentially related to this issue:

1. Which is the immutable part of a Request that can currently be used for hashing?
2. Is it better to have requests mutable? After all, a request is something received from outside as is, and if we need to create one internally we should build a new one. Or am I looking at this completely wrong?

Thank you!

from starlette.

Which is the immutable part of a Request that can currently be used for hashing?

The scope represents the state, although the receive/send channels necessarily represent non-hashable elements of the request. Question really is - what do you mean wrt. hashing requests, and what's the intent? Do you want to uniquely identify each incoming request individually, or do you want to do something where the "uniqueness" is a property of the method and request URL?

Is it better to have requests mutable?

Mixed bag. It'd be a benefit if it promotes clearer development practice.

from starlette.

Well I was looking at SQLAlchemy and its approach to sessions (as per https://docs.sqlalchemy.org/en/13/orm/contextual.html#unitofwork-contextual), which got me thinking about (im)mutability of requests in general. (I am aware of the issues with using sync libraries with async framework, and I am also aware -- and have used -- the databases and orm projects; just been experimenting a bit.)

from starlette.