If we drop py33, then those lines are not required, and can be removed, correct?
domenkozar
yeah :)
stevepie_
...and move Jinja2 and MarkupSafe into requires, of course
i reckon we should cut a release when dropping and adding support for various pythons, too
but i'll leave that to you as package manager, if that's OK
domenkozar
happy to do that :)
refresh my python packaging foo
stevepie_
ok, i'm fading, long day, but i'll get this started and hopefully finish later today
domenkozar
stevepie_: take it easy, there's no rush.
econoraptorman has quit
dfee joined the channel
dfee has quit
hvelarde|away is now known as hvelarde
brokencycle joined the channel
Belxjander joined the channel
ztane
quart and flask wishing for a merge...
Belxjander joined the channel
betabug
put a quart of something in a flask?
ztane
quart is an asgi framework that is almost 100 % flask api compatible, plus some await, async...
something like that is needed for pyramid... ofc no one knows yet how it is going to work in Flask...
the thing with quart is that everything is lazy,
so you can await request.form (request.POST) - the request as such can have its processing start, routing done even before the entire request is received...
Belxjander joined the channel
asthasr joined the channel
asthasr
So, I'm wondering what solution people use for "dynamic" json renderers, where you can include or omit certain properties on certain objects based on the needs of an endpoint, without having to make a custom renderer for each endpoint
I settled on something where I'm sticking parameters in the request object, which the adapters can read... but it feels gross.
A good example might be where a manager has permission to view more data than a customer service rep.
ztane
asthasr: so if you can stick it to the request, sure you can decorate the *response* too
or just flter in the request, or in a decorator!
so depends
asthasr
well, sure, I guess I could modify the response (although I'm not sure it has anything as general as "add_request_method"). That still doesn't thrill me, though; it's still a sort of non-obvious side channel of input, right?
erasmas joined the channel
brokencycle_ joined the channel
dfee joined the channel
dfee has quit
jcarl43 joined the channel
tiwula joined the channel
zepolen_ joined the channel
zepolen has quit
El_Rolando has quit
Ademan-remote has quit
bbradley_ joined the channel
mcdonc
asthasr: would it be better to just cause the view to do the authorization checks and output only what is necessary and let the renderer stay static
(this is what i do, in any case)
asthasr
mcdonc: So then how do you avoid writing what are essentially custom serialization functions for each view? e.g. if you're outputting an ORM object, you'll end up with a function for each view that returns it as part of a payload?
dfee joined the channel
mcdonc
in my conception of the world, that's the view's job; sometimes i'll write some shared logic as functions to do that serialization
it's just kind of a matter of where you put the code; the serialization has to go somewhere
and given that you'd need to establish some sort of protocol between the view code and the renderer to tell it how to serialize
i'd just put it in the view
if it's some sort of framework maybe i'd do more than that
asthasr
but then, if you have shared logic, do you just repeat it?
mcdonc
sometimes. usually not. i'll just break it out into a function or use a base class with the shared logic.
but if you do want to get more frameworky
and have pyramid do something special whenever a certain kind of object is returned