Yury Selivanov wrote:
1. So essentially this means that we will have one "local context" per
context manager storing one value.
I can't see that being a major problem. Context vars will
(I hope!) be very rare things, and needing to change a
bunch of them in one function ought to be rarer still.
But if you do, it would be easy to provide a context
manager whose sole effect is to introduce a new context:
with new_local_context():
cvar1.set(something)
cvar2.set(otherthing)
...
2. If somebody makes a mistake and calls "push_local_context" without
a corresponding "pop_local_context"
You wouldn't normally call them directly, they would be
encapsulated in carefully-written context managers. If you
do use them, you're taking responsibility for using
them correctly.
If it would make you feel happier, they could be named
_push_local_context and _pop_local_context to emphasise
that they're not intended for everyday use.
3. Users will need to know way more to correctly use the mechanism.
Most users will simply be using already-provided context
managers, which they're *already used to doing*. So they
won't have to know anything more than they already do.
See my last decimal example, which required *no change*
to existing correct user code.
So far, both you and Koos can't give us a realistic example which
illustrates why we should suffer the implications of (1), (2), and
(3).
And you haven't given a realistic example that convinces me
your proposed with-statement-elimination feature would be of
significant benefit.
--
Greg
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
