The substitute for 'use=lambda' in new API about webargs HOT 8 CLOSED

Thanks @dwieeb!

Another way to get the same functionality as use is through a custom field.

class Use(fields.Field):

    def __init__(self, func, child=None, **kwargs):
        super().__init__(**kwargs)
        self.func = func
        self.child = child

    def _deserialize(self, value, attr, data):
        if self.child:
            value = self.child.deserialize(value, attr, data)
        return self.func(value)

@use_args({
    'foo': Use(lambda v: v.upper(), fields.Str())
})
def myview(args):
    #...

from webargs.

Interesting. Perhaps this could exist in the webargs codebase as fields.Lambda or fields.Alter or something?

from webargs.

Perhaps in the future. In the interest of keeping the core small, I'm going to hold off on adding this to the code base for now.

from webargs.

👍 I agree.

Besides, I think I would actually prefer the marshmallow solution, as it allows access to other fields and does not require custom fields.

Thanks for webargs. With the marshmallow integration it's the best solution out there even without being "stable"... And I've used pretty much everything out there for flask, including rolling my own.

from webargs.

Thanks for the encouraging words!

from webargs.

I've moved this to the Wiki here: https://github.com/sloria/webargs/wiki/Recipes . Thanks again @dwieeb !

from webargs.

You didn't need to do that; I'm not sure if a migration guide of a lesser used feature from an alpha version is helpful to people, especially as the 1.0 code base matures.

What's more important is that the documentation somehow shows the pre-processing and post-processing of schemas. Currently, there's just a link to the marshmallow api in the "marshmallow integration" section. People coming into webargs with no prior marshmallow experience may be looking in the docs for how to process values before they enter their route functions. Right now, it looks as if webargs doesn't have this.

I could get around to writing up something for the docs if I find time.

from webargs.

I agree; I think it would be useful to have some documentation for pre- and post-processing behavior. I would certainly welcome a PR.

from webargs.