Are query based blueprint arguments after path arguments formally unsupported?

[palomino79]

Are query based blueprint arguments after path arguments formally unsupported?

[greyli]

@lafrech webargs 8.3.0 added a USE_ARGS_POSITIONAL config for the parser, you can enable this in flask-smorest to ensure the argument order (actually you don't need to care about the order since all args are in keyword argument). See the docs for more detail: https://webargs.readthedocs.io/en/latest/advanced.html#argument-passing-and-arg-name

This would be a breaking change so I released APIFlask 2.0 for this change (apiflask/apiflask#450).

Related discussion: marshmallow-code/webargs#830, marshmallow-code/webargs#833

[lafrech]

Yeah, it works if you write

    def get(self, query_args, pet_id):

The order is not intuitive. I live with it but I admit it kinda sucks.

@greyli has been working on arguments order for APIFlask. I don't know if this also affected path parameters. I believe it involved overriding an underscored method, but maybe things have changed since then.

[palomino79]

@lafrech Thanks for the insight. That threw me off in a big way, but your example was spot on. I might try to add a note in arguments.rst to explain this, as I never would have thought to prepend the query argument dictionaries before the path argument in the get() method, unless you had let me know to do that, if that's alright.

[lafrech]

Sure.

There is an example hidden in the quickstart, already, but an explicit statement in "arguments" docs wouldn't hurt.

@blp.route("/<pet_id>")
class PetsById(MethodView):

    [...]

    @blp.arguments(PetSchema)
    @blp.response(200, PetSchema)
    def put(self, update_data, pet_id):
        """Update existing pet"""

[lafrech]

Good point. I didn't take the time to try this in flask-smorest. I think I'll make extensive use of the arg_name argument as I like view function arguments to have meaningful names (pet vs. json_data).

I'm wondering if this is something that has to be forced in flask-smorest or if users may be allowed to choose. For now flask-smorest has always let the user set the value of use_kwargs.

In fact, I didn't try it but users should be able to set that parser attribute themselves without any change to flask-smorest. And since we pass kwargs transparently, they can even pass arg_name.