Broad types accepted by the starlite constructor. #1134
Closed
peterschutt
started this conversation in
Potential Issues
Replies: 3 comments
-
I think it's a good idea to narrow the types down. It's also more consistent, since we do this in some parts already. As for the state specifically, I think #1111 also plays into this. If you can use a custom state class, it would make a lot of sense that it can be used as an initial state object as well. |
Beta Was this translation helpful? Give feedback.
0 replies
-
OK I've done a pass over the app/router/controller/handler parameters in #1140 for 2.0. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
As a very specific example, I have a question of the need for the application instance to receive anything other than a dict as the value for the
initial_state
parameter. By acceptingImmutableState
andtuple[str, Any]
it makes it a lot harder for plugins to use the app state if they need to.Handlers end up having to do lots of state checking before they can do anything.. and if
initial_state
is an instance of immutable state, then they can't really use it. Writing plugins where initial state may be immutable means that you cannot really use it downstream reliably (you can if the plugin is a personal thing, but as soon as you want to publish it as a library you can't).We could have another app/config parameter
app_state_immutable
orapp_state_type: type[ImmutableState] = State
which could be used to indicate whether the application state that is constructed should be eitherImmutableState
orState
, and I don't think it would be too unreasonable to ask users to pass dict(initial_state) to the constructor if they do have a sequence of k/v pairs.Less specifically, we also accept a few parameters that can be either scalar, or a list. I get that this is something of a convenience, but we are only talking about asking users to provide
...=[handler]
instead of...=handler
, which I'd be very surprised if we ever received complaints about. Again from a plugin perspective, before one can interact with any of the attributes that might be a list or a scalar, they need to use something like this (which is an actual helper I use instarlite-saqlalchemy
):So I'd like to gauge the community feelings about simplifying these params to the constructor for 2.0.
Beta Was this translation helpful? Give feedback.
All reactions