Hi Nick,
Thanks for writing this! You reminded me that it's crucial to have an
ability to fully recreate generator behaviour in an iterator. Besides
this being a requirement for a complete EC model, it is something that
compilers like Cython absolutely need.
I'm still working on a rewrite (which
On 15 August 2017 at 05:25, Yury Selivanov wrote:
> Nick, you nailed it with your example.
>
> In short: current PEP 550 defines Execution Context in such a way,
> that generators and iterators will interact differently with it. That
> means that it won't be possible to refactor an iterator class
Nick, you nailed it with your example.
In short: current PEP 550 defines Execution Context in such a way,
that generators and iterators will interact differently with it. That
means that it won't be possible to refactor an iterator class to a
generator and that's not acceptable.
I'll be rewriting
Hi Barry,
Yes, i18n is another use-case for execution context, and ec should be
a perfect fit for it.
Yury
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf
Yury Selivanov wrote:
> This is a new PEP to implement Execution Contexts in Python.
It dawns on me that I might be able to use ECs to do a better job of
implementing flufl.i18n's translation contexts. I think this is another
example of what the PEP's abstract describes as "Context managers like
On Mon, Aug 14, 2017 at 12:56 PM, Guido van Rossum wrote:
> Could someone (perhaps in a new thread?) summarize the current proposal,
> with some examples of how typical use cases would look? This is an important
> topic but the discussion is way too voluminous for me to follow while I'm on
> vacat
Could someone (perhaps in a new thread?) summarize the current proposal,
with some examples of how typical use cases would look? This is an
important topic but the discussion is way too voluminous for me to follow
while I'm on vacation with my family, and the PEP spends too many words on
motivation
On 14 August 2017 at 02:33, Yury Selivanov wrote:
> On Sat, Aug 12, 2017 at 10:09 PM, Nick Coghlan wrote:
>> That similarity makes me wonder whether the "isolated or not"
>> behaviour could be moved from the object being executed and directly
>> into the key/value pairs themselves based on whethe
On Sun, Aug 13, 2017 at 3:14 PM, Nathaniel Smith wrote:
> On Sun, Aug 13, 2017 at 9:57 AM, Yury Selivanov
> wrote:
>> 2. ContextItem.has(), ContextItem.get(), ContextItem.set(),
>> ContextItem.delete() -- pretty self-explanatory.
>
> It might make sense to simplify even further and declare that
On Sun, Aug 13, 2017 at 9:57 AM, Yury Selivanov wrote:
> 2. ContextItem.has(), ContextItem.get(), ContextItem.set(),
> ContextItem.delete() -- pretty self-explanatory.
It might make sense to simplify even further and declare that context
items are initialized to None to start, and the only operat
I'll start a new thread to discuss is we want this specific semantics
change soon (with some updates).
Yury
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf
[replying to the list]
On Sun, Aug 13, 2017 at 6:14 AM, Nick Coghlan wrote:
> On 13 August 2017 at 16:01, Yury Selivanov wrote:
>> On Sat, Aug 12, 2017 at 10:56 PM, Nick Coghlan wrote:
>> [..]
>>> As Nathaniel suggestion, getting/setting/deleting individual items in
>>> the current context woul
On Sat, Aug 12, 2017 at 10:09 PM, Nick Coghlan wrote:
> On 13 August 2017 at 03:53, Yury Selivanov wrote:
>> On Sat, Aug 12, 2017 at 1:09 PM, Nick Coghlan wrote:
>>> Now that you raise this point, I think it means that generators need
>>> to retain their current context inheritance behaviour, si
>> This is a new PEP to implement Execution Contexts in Python.
> The idea is of course great!
Thanks!
> A couple of issues for decimal:
>
>> Moreover, passing the context explicitly does not work at all for
>> libraries like ``decimal`` or ``numpy``, which use operator overloading.
>
> Instead
Hi Pau,
Re string keys collisions -- I decided to update the PEP to follow
Nathaniel's suggestion to use a get_context_key api, which will
eliminate this problem entirely.
Re call_soon in asyncio.Task -- yes, it does use ec.run() to invoke
coroutine.send(). However, this has almost no visible eff
Hi Jonathan,
Thanks for the feedback. I'll update the PEP to use Nathaniel's idea
of of `sys.get_context_key`. It will be a pretty similar API to what
you currently have in prompt_toolkit.
Yury
___
Python-ideas mailing list
Python-ideas@python.org
https
Finally got an almost decent internet connection.
Seeing the changes related to that PEP I can confirm that the context
will be saved twice in any "task switch" in an Asyncio environment.
Once made by the run in context function executed by the Handler [1]
and immediately after by the send [2] met
For what it's worth, as part of prompt_toolkit 2.0, I implemented something
very similar to Nathaniel's idea some time ago.
It works pretty well, but I don't have a strong opinion against an
alternative implementation.
- The active context is stored as a monotonically increasing integer.
- For eac
On Sat, Aug 12, 2017 at 10:12 AM, Nick Coghlan wrote:
[..]
>
> 1. Are you sure you want to expose the CoW type to pure Python code?
Ultimately, why not? The execution context object you get with
sys.get_execution_context() is yours to change. Any change to it won't
be propagated anywhere, unless
On Sat, Aug 12, 2017 at 10:56 PM, Nick Coghlan wrote:
[..]
> As Nathaniel suggestion, getting/setting/deleting individual items in
> the current context would be implemented as methods on the ContextItem
> objects, allowing the return value of "get_context_items" to be a
> plain dictionary, rather
On Sat, Aug 12, 2017 at 9:05 PM, Nick Coghlan wrote:
> On 13 August 2017 at 12:15, Nathaniel Smith wrote:
>> On Sat, Aug 12, 2017 at 6:27 PM, Yury Selivanov
>> wrote:
>>> Yes, I considered this idea myself, but ultimately rejected it because:
>>>
>>> 1. Current solution makes it easy to introsp
On 13 August 2017 at 12:15, Nathaniel Smith wrote:
> On Sat, Aug 12, 2017 at 6:27 PM, Yury Selivanov
> wrote:
>> Yes, I considered this idea myself, but ultimately rejected it because:
>>
>> 1. Current solution makes it easy to introspect things. Get the
>> current EC and print it out. Although
[replying to list]
On Sat, Aug 12, 2017 at 10:56 PM, Nick Coghlan wrote:
> On 13 August 2017 at 11:27, Yury Selivanov wrote:
>> Yes, I considered this idea myself, but ultimately rejected it because:
>>
>> 1. Current solution makes it easy to introspect things. Get the
>> current EC and print it
On 13 August 2017 at 11:27, Yury Selivanov wrote:
> Yes, I considered this idea myself, but ultimately rejected it because:
>
> 1. Current solution makes it easy to introspect things. Get the
> current EC and print it out. Although the context item idea could be
> extended to `sys.create_context_
As far as providing a thread-local like surrogate for coroutine based
systems in Python, we had to solve this for Twisted with
https://bitbucket.org/hipchat/txlocal. Because of the way the Twisted
threadpooling works we also had to make a context system that was both
coroutine and thread safe at th
On Sat, Aug 12, 2017 at 6:27 PM, Yury Selivanov wrote:
> Yes, I considered this idea myself, but ultimately rejected it because:
>
> 1. Current solution makes it easy to introspect things. Get the
> current EC and print it out. Although the context item idea could be
> extended to `sys.create_con
On 13 August 2017 at 03:53, Yury Selivanov wrote:
> On Sat, Aug 12, 2017 at 1:09 PM, Nick Coghlan wrote:
>> Now that you raise this point, I think it means that generators need
>> to retain their current context inheritance behaviour, simply for
>> backwards compatibility purposes. This means tha
Yes, I considered this idea myself, but ultimately rejected it because:
1. Current solution makes it easy to introspect things. Get the
current EC and print it out. Although the context item idea could be
extended to `sys.create_context_item('description')` to allow that.
2. What if we want to p
I had an idea for an alternative API that exposes the same
functionality/semantics as the current draft, but that might have some
advantages. It would look like:
# a "context item" is an object that holds a context-sensitive value
# each call to create_context_item creates a new one
ci = sys.creat
Good work Yuri, going for all in one will help to not increase the
diferences btw async and the sync world in Python.
I do really like the idea of the immutable dicts, it makes easy inherit the
context btw tasks/threads/whatever without put in risk the consistency if
there is further key colisions
Nathaniel, Nick,
I'll reply only to point 9 in this email to split this threads into
manageable sub-threads. I'll cover other points in later emails.
On Sat, Aug 12, 2017 at 3:54 AM, Nathaniel Smith wrote:
> 9. OK, my big question, about semantics.
FWIW I took me a good hour to fully understan
On Sat, Aug 12, 2017 at 2:28 PM, rym...@gmail.com wrote:
> So, I'm hardly an expert when it comes to things like this, but there are
> two things about this that don't seem right to me. (Also, I'd love to
> respond inline, but that's kind of difficult from a mobile phone.)
>
> The first is how set
Sure, I'll do.
Yury
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
So, I'm hardly an expert when it comes to things like this, but there are
two things about this that don't seem right to me. (Also, I'd love to
respond inline, but that's kind of difficult from a mobile phone.)
The first is how set/get_execution_context_item take strings. Inevitably,
people are go
Nick, Nathaniel, I'll be replying in full to your emails when I have
time to do some experiments. Now I just want to address one point
that I think is important:
On Sat, Aug 12, 2017 at 1:09 PM, Nick Coghlan wrote:
> On 12 August 2017 at 17:54, Nathaniel Smith wrote:
>> ...and now that I've wri
On 12 August 2017 at 17:54, Nathaniel Smith wrote:
> ...and now that I've written that down, I sort of feel like that might
> be what you want for all the other sorts of context object too? Like,
> here's a convoluted example:
>
> def gen():
> a = decimal.Decimal("1.111")
> b = decimal.Dec
Thanks for the explanation. Can you make sure this is explained in the PEP?
On Aug 11, 2017 10:43 PM, "Yury Selivanov" wrote:
> > On Fri, Aug 11, 2017 at 10:17 PM, Guido van Rossum
> wrote:
> > > I may have missed this (I've just skimmed the doc), but what's the
> rationale
> > > for making the
On 12 August 2017 at 15:45, Yury Selivanov wrote:
> Thanks Eric!
>
> PEP 408 -- Standard library __preview__ package?
Typo in the PEP number: PEP 406, which was an ultimately failed
attempt to get away from the reliance on process globals to manage the
import system by encapsulating the top level
On 12 August 2017 at 08:37, Yury Selivanov wrote:
> Hi,
>
> This is a new PEP to implement Execution Contexts in Python.
>
> The PEP is in-flight to python.org, and in the meanwhile can
> be read on GitHub:
>
> https://github.com/python/peps/blob/master/pep-0550.rst
>
> (it contains a few diagrams
Yury Selivanov wrote:
> This is a new PEP to implement Execution Contexts in Python.
The idea is of course great!
A couple of issues for decimal:
> Moreover, passing the context explicitly does not work at all for
> libraries like ``decimal`` or ``numpy``, which use operator overloading.
Ins
Hi Yury,
This is really cool. Some notes on a first read:
1. Excellent work on optimizing dict, that seems valuable independent
of the rest of the details here.
2. The text doesn't mention async generators at all. I assume they
also have an agi_isolated_execution_context flag that can be set, to
Thanks Eric!
PEP 408 -- Standard library __preview__ package?
Yury
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
> On Fri, Aug 11, 2017 at 10:17 PM, Guido van Rossum wrote:
> > I may have missed this (I've just skimmed the doc), but what's the rationale
> > for making the EC an *immutable* mapping? It's impressive that you managed
> > to create a faster immutable dict, but why does the use case need one?
>
[replying to the list]
> I may have missed this (I've just skimmed the doc), but what's the rationale
> for making the EC an *immutable* mapping?
It's possible to implement Execution Context with a mutable mapping
and copy-on-write (as it's done in .NET) This is one of the approaches
that I trie
On Fri, Aug 11, 2017 at 10:17 PM, Guido van Rossum wrote:
> I may have missed this (I've just skimmed the doc), but what's the rationale
> for making the EC an *immutable* mapping? It's impressive that you managed
> to create a faster immutable dict, but why does the use case need one?
In this pr
I may have missed this (I've just skimmed the doc), but what's the
rationale for making the EC an *immutable* mapping? It's impressive that
you managed to create a faster immutable dict, but why does the use case
need one?
--
--Guido van Rossum (python.org/~guido)
On Aug 11, 2017 16:38, "Yury Selivanov" wrote:
Hi,
This is a new PEP to implement Execution Contexts in Python.
Nice! I've had something like this on the back burner for a while as it
helps solve some problems with encapsulating the import state (e.g. PEP
408).
-eric
> This is exciting and I'm happy that you're addressing this problem.
Thank you!
> Some of our use cases can't be implemented using this PEP; notably, we use a
> timing context that times how long an asynchronous function takes by
> repeatedly pausing and resuming the timer.
Measuring performa
This is exciting and I'm happy that you're addressing this problem.
We've solved a similar problem in our asynchronous programming framework,
asynq. Our solution (implemented at
https://github.com/quora/asynq/blob/master/asynq/contexts.py) is similar to
that in PEP 521: we enhance the context mana
[duplicating my reply cc-ing python-ideas]
> Is a new EC type really needed? Cannot this be done with collections.ChainMap?
No, not really. ChainMap will have O(N) lookup performance where N
is the number of contexts you have in the chain. This will degrade
performance of lookups, which isn't acc
Hi,
Is a new EC type really needed? Cannot this be done with
collections.ChainMap?
2017-08-12 0:37 GMT+02:00 Yury Selivanov :
> Hi,
>
> This is a new PEP to implement Execution Contexts in Python.
>
> The PEP is in-flight to python.org, and in the meanwhile can
> be read on GitHub:
>
> https://g
Hi,
This is a new PEP to implement Execution Contexts in Python.
The PEP is in-flight to python.org, and in the meanwhile can
be read on GitHub:
https://github.com/python/peps/blob/master/pep-0550.rst
(it contains a few diagrams and charts, so please read it there.)
Thank you!
Yury
PEP: 550
52 matches
Mail list logo