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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4