Removing Schema context feels like a bad idea!

[ThiefMaster]

Maybe this is subjective, but it feels like the removal of context makes previously simple tasks much more cumbersome and verbose...

Correct my if I'm wrong, but it looks like you expect context to be completely handled outside marshmallow using basically global variables (yes, I know, contextvars are better than that, but both are similarly "loose").

For example, quite a few schemas require access to user for which the dumping happens, e.g. to filter out certain data post-dump or to include information on whether the user can do certain operations with the object being dumped. In both cases, I've been using MySchema(context={'user': session.user}) so the schema itself is agnostic to request state - any user could be passed in via the schema, not necessarily the currently logged-in user. Inside the schema it was trivial to use self.context[...] in Method fields or hooks.

Now, however, unless I'm missing something, ALL this functionality is gone, and I'm expected to create a new class for the context, and import it both for passing context and for receiving it (YAY for circular import issues, they were already bad enough before especially when using SQLAlchemy model schemas). It all becomes much more verbose.

A simple self.context['user'] to access it vs something like Context[UserContext].get()['user'] or Context[UserContext].get() (haven't actually tested v4 yet, so not sure how exactly it works).

And honestly, I'm absolutely not looking forward to fixing over 50 occurrences of self.context plus roughly the same number of places where it's being passed to a schema...

The description of #2707 still mentions that "Context can be passed in dump/load call or set in a context manager" but I can't see this in the docs nor the PR's code. So this never happened I guess?

[lafrech]

Using current logged-in user is typically something context vars implementation is good for. IIUC, your use case is about creating a schema instance referencing a user while being used by another user, the referenced user being passed at schema instantiation. For this, you could subclass Schema to pass that "context" at __init__. In fact, you could call it context and keep the existing calls

MySchema(context={'user': whoever})

then while loading/dumping

user = self.context["user"]

The point of the context feature is to add information to a schema instance. There is no magic required to add information when instantiating a schema.

The description of #2707 still mentions that "Context can be passed in dump/load call or set in a context manager" but I can't see this in the docs nor the PR's code. So this never happened I guess?

It happened in the first version of the PR then was removed (see conversation). The docs are correct.

[StickKing]

I support the author of the issue. It (context) has become more cumbersome and inconvenient to use. I would also like to note that, in my opinion, introducing a new experimental version of context while simultaneously removing the old version is a strange decision.

[lafrech]

Please read the discussions in #2707.

Basically, the old feature was buggy by design, and it seemed the same could be achieved neatly using context variables.

While developing, we came to realize that there was no adherence in the code to the context manager feature. I mean nowhere was it called in the code, it was all in user land. So we figured let's remove it altogether from the code and document how to do.

Ultimately, we ended up doing more than a doc: we provided an example implementation as an "experimental" feature. Experimental because we may want to modify it considering user feedback.

I still think context manager / variables in user code cover most use cases and I encourage users to provide examples of use cases that are not covered.

I understand it may seem more cumbersome but I think it is better than buggy and once the context manager is defined, the use looks pretty neat to me.