Should `parse` allow arguments to be passed through to `schema.load` and/or `dict2schema`?

I’m looking at the features of marshmallow and Parser.parse (and, by extension, use_args too) and thinking about whether or not this will expose more marshmallow features while not adding too much code (or even, my real goal, simplifying things?).

I have two basic ideas I’m toying with:

1. the validate argument to parse is basically the same as a schema with validates_schema methods
   • but the validate errors have slightly different messages – they don’t show the schema name (is that good for generated schemas? can a validates_schema method do that?)
   • can these be unified, maybe deprecate validate=..., and remove in 7.0 or later?
2. there’s no way to tell parse to pass unknown to schema.load – it would be nice to be able to say parse(..., unknown=ma.EXCLUDE)
   • should this just be a container for schema.load arguments, like parse(..., load_params=dict(unknown=ma.INCLUDE, partial=True))? It’s a less nice interface to use but more flexible
   • you can handle this today by making different schema objects with your desired behaviors
   • maybe this is doable along with (1) for the dict2schema case by setting attributes of Meta?

This is really low priority. You can do everything today in 6 by using full schema definitions. Supporting unknown=... or load_params=... is really just a convenience feature.

[sirosen]

It’s only a pity for people using dicts rather than Schemas, with a validation involving several fields, and simple enough to be expressed in a lambda.

I’m not sure, but it sounds like you might be suggesting simply dropping validate=... in a future release, since it’s only one narrow case that’s hurt by this? I’d be okay with that.

We could change the docs around to use more explicit schema classes in the examples, and shift to preferring schemas over dicts throughout the documentation.

---

Let’s maybe just drop (2) from discussion – it’s only really relevant for the “dict schema” usage, and I think it’s fine to just say that that usage is less flexible and “you should use real schemas if you want more features”.

Wondering how this would fit with auto-documentation à la apispec.

I haven’t used apispec, but I think this is another reason not to bend over backwards to handle “dict schemas” better. Users can always (on marshmallow3) just use myschema = ma.Schema.from_dict(...)() themselves, if they’re determined not to use the class keyword! 😝

[sirosen]

We have #507 which tracks the unknown behavior – and we’re working on actually implementing that – so I’m going to close this. Especially given that webargs 7 is going to have per-location defaults for unknown, I don’t think the idea of passing through arbitrary arguments is very compelling.