Le 3 janv. 2018 06:05, "Yury Selivanov" a écrit :
tuples in Python are immutable, but you can have a tuple with a dict as its
single element. The tuple is immutable, the dict is mutable.
At the C level we have APIs that can mutate a tuple though.
Now, tuple is not a direct analogy to Context, b
> On Jan 3, 2018, at 12:26 PM, Victor Stinner wrote:
>
> Le 3 janv. 2018 06:05, "Yury Selivanov" a écrit :
> tuples in Python are immutable, but you can have a tuple with a dict as its
> single element. The tuple is immutable, the dict is mutable.
>
> At the C level we have APIs that can muta
Le 3 janv. 2018 06:34, "Guido van Rossum" a écrit :
I think the issue here is a bit different than Yury's response suggests --
it's more like how a variable containing an immutable value (e.g. a string)
can be modified, e.g.
x = 'a'
x += 'b'
In our case the *variable* is the current thread stat
Le 3 janv. 2018 06:38, "Guido van Rossum" a écrit :
But is there a common use case? For var.get() I'd rather just pass the
default or catch the exception if the flow is different. Using ctx[var] is
rare (mostly for printing contexts, and perhaps for explaining var.get()).
I don't think that it
I think we can expose the default property. If it's not set we can return
MISSING.
Yury
Sent from my iPhone
> On Jan 3, 2018, at 1:04 PM, Victor Stinner wrote:
>
> Le 3 janv. 2018 06:38, "Guido van Rossum" a écrit :
> But is there a common use case? For var.get() I'd rather just pass the
>
On 28 December 2017 at 06:08, Yury Selivanov wrote:
> This is a second version of PEP 567.
Overall, I like the proposal. It's relatively straightforward to follow, and
makes sense.
One thing I *don't* see in the PEP is an example of how code using thread-local
storage should be modified to use c
Generally I think programming language implementers don't get to
decide how the language works. You just have to implement it as
specified, inconvenient as that might be.
However, from a languge design prespective, I think there is a good
argument that this is a corner of the language we should co
Hello,
I've tried reading various RFCs around Base64 encoding, but I couldn't make the
ends meet. Yet there is an inconsistency between base64.decodebytes() and
base64.decode() in that how they handle linebreaks that were used to collate
the encoded text. Below is an example of what I'm talki
I like the Guido's proposal, i.e.
if '__repr__' not in cls.__dict__:
... # generate the method
etc. I didn't find an issue to track this. Maybe we should open one?
--
Ivan
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyth
Victor:
> ContextVar would be simpler if the default would be mandatory as well :-)
If we modify ContextVar to use None as the default value, the 'default'
parameter of ContextVar.get() becomes useless, ContextVar.get() and
context[var] behaviour becomes obvious. Token.MISSING could also be remove
> Do you have any use case for modifying a variable inside some context?
> numpy, decimal, or some sort of tracing for http requests or async
frameworks like asyncio do not need that.
Maybe I misunderstood how contextvars is supposed to be used. So let me
give you an example.
I understand that d
I’ll open an issue after I have time to read this thread and comment on it.
--
Eric.
> On Jan 3, 2018, at 12:31 PM, Ivan Levkivskyi wrote:
>
> I like the Guido's proposal, i.e.
>
> if '__repr__' not in cls.__dict__:
> ... # generate the method
>
> etc. I didn't find an issue to
I think decimal is a bit of a red herring, because the entire decimal
context is stored as a single thread-local variable
(_local.__decimal_context__ in _pydecimal.py, where _local is a global
threading.local instance; using "___DECIMAL_CTX__" as a key in the C-level
dict of thread-locals in the C
02.01.18 22:31, Neil Schemenauer пише:
Serhiy Storchaka wrote:
Currently 'break' and 'return' are never used inside 'finally'
clause in the stdlib.
See the _recv_bytes() function:
Lib/multiprocessing/connection.py: 316
Thank you Neil! I missed this case because ran only fast tests, without
On 1/3/2018 11:16 AM, Guido van Rossum wrote:
Maybe I should clarify again what run() does. Here's how I think of it
in pseudo code:
def run(self, func, *args, **kwds):
old = _get_current_context()
new = old.copy()
_set_current_context(new)
try:
return func(*args, **kwds
On 2018-01-03, Serhiy Storchaka wrote:
> I haven't found 'finally' clauses in
> https://github.com/gevent/gevent/blob/master/src/gevent/libev/corecffi.py.
> Perhaps this code was changed in recent versions.
Yes, I was looking at was git revision bcf4f65e. I reran my AST
checker and found this:
.
On Wed, Jan 3, 2018 at 12:32 PM, Glenn Linderman
wrote:
> On 1/3/2018 11:16 AM, Guido van Rossum wrote:
>
> Maybe I should clarify again what run() does. Here's how I think of it in
> pseudo code:
>
> def run(self, func, *args, **kwds):
> old = _get_current_context()
> new = old.copy()
>
I'm sorry, I don't think more research can convince me either way. I want
all three of return/break/continue to work inside finally clauses, despite
there being few use cases.
On Wed, Jan 3, 2018 at 2:30 PM, Neil Schemenauer
wrote:
> On 2018-01-03, Serhiy Storchaka wrote:
> > I haven't found 'fi
2018-01-03 23:01 GMT+01:00 Guido van Rossum :
> Heh, you're right, I forgot about that. It should be more like this:
>
> def run(self, func, *args, **kwds):
> old = _get_current_context()
> _set_current_context(self) # <--- changed line
> try:
> return func(*args, **kwds)
>
Ok, I finally got access to a computer and I was able to test the PEP
567 implementation: see my code snippet below.
The behaviour is more tricky than what I expected. While running
context.run(), the context object is out of sync of the "current
context". It's only synchronized again at run() exi
Oh, dang, I forgot about this. ContextVar.set() modifies the current
Context in-place using a private API. In the PEP, asyncio copies the
Context once and then calls run() repeatedly (for each _step call). So
run() isn't stateless, it just saves and restores the notion of the current
context (in th
That was actually Yury's original design, but I insisted on a Mapping so
you can introspect it. (There needs to be some way to introspect a Context,
for debugging.) Again, more later. :-(
On Wed, Jan 3, 2018 at 4:44 PM, Victor Stinner
wrote:
> Ok, I finally got access to a computer and I was abl
I opened https://bugs.python.org/issue32491 so this wouldn't be lost under
the assumption that you'll eventually resolve your bugtracker account
situation. :)
I don't know what the correct behavior *should* be but agree that it seems
odd for decode to behave different than decodebytes.
-gps
On W
2018-01-04 0:44 GMT+01:00 Victor Stinner :
> The behaviour is more tricky than what I expected. While running
> context.run(), the context object is out of sync of the "current
> context". It's only synchronized again at run() exit. So
> ContextVar.set() doesn't immediately modifies the "current co
On 2018-01-03, Guido van Rossum wrote:
> I'm sorry, I don't think more research can convince me either way.
> I want all three of return/break/continue to work inside finally
> clauses, despite there being few use cases.
That's fine. The history of 'continue' inside 'finally' is
interesting. The
On Wed, Jan 3, 2018 at 3:44 PM, Victor Stinner wrote:
> Ok, I finally got access to a computer and I was able to test the PEP
> 567 implementation: see my code snippet below.
>
> The behaviour is more tricky than what I expected. While running
> context.run(), the context object is out of sync of
Hi,
It seems like many people, including myself, are confused by the lack
of concrete current context in the PEP 567 (contextvars). But it isn't
difficult to implement the current context (I implemented it, see
below). It might have a *minor* impact on performance, but Context
mapping API is suppo
Victor:
> I modified Context mapping API to use the context variables from the
> current thread state if it's the current thread state.
Oops, I mean: "if it's the current context".
Nathaniel:
"""
- BUT it doesn't allow mutation through the MutableMapping interface;
instead, the only way to mutate
On Wed, Jan 3, 2018 at 5:42 PM, Victor Stinner wrote:
> Hi,
>
> It seems like many people, including myself, are confused by the lack
> of concrete current context in the PEP 567 (contextvars). But it isn't
> difficult to implement the current context (I implemented it, see
> below).
The problem
Guido van Rossum wrote:
There needs to be some way to introspect a
Context, for debugging.
It could have a read-only introspection interface without
having to be a full Mapping.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.
Guido van Rossum wrote:
contextvars.copy_context().run(func, )
If contexts are immutable, why is there something
called copy_context?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubs
Hello!
I'd like to draw some attention to the feature(s) proposed in the issue
31299. https://bugs.python.org/issue31299 It's a dependency of the other
issue, it still needs discussion, and it hasn't received any comments from
committers since last September.
Personally, I think that a general tr
2018-01-04 3:15 GMT+01:00 Nathaniel Smith :
> The problem with such an API is that it doesn't work (or at the very
> least creates a lot of complications) in a potential future PEP 550
> world, (...)
Hum, it's annoying that many design choices of the PEP 567 are
motivated by the hypothetical accep
On Jan 3, 2018 18:38, "Dmitry Kazakov" wrote:
Hello!
I'd like to draw some attention to the feature(s) proposed in the issue
31299. https://bugs.python.org/issue31299 It's a dependency of the other
issue, it still needs discussion, and it hasn't received any comments from
committers since last S
34 matches
Mail list logo
