On Mon, Jun 21, 2021 at 7:20 PM Mark Gordon wrote:
> > Yeah, it would indeed inherit the copy. We could, theoretically, make
> > asyncio.Task accept context objects and not copy them, but what would
> that
> > give us?
>
> My main thinking was to just be similar to the closest synchronous analog
> However this is not exactlly the same as the task will inherit a copy of
my_context rather than running directly on my_context.
Yeah, it would indeed inherit the copy. We could, theoretically, make
asyncio.Task accept context objects and not copy them, but what would that
give us? If a coroutine
On Wed, Jul 22, 2020 at 9:25 PM Marco Sulla
wrote:
<...>
> On Wed, 22 Jul 2020 at 18:26, Guido van Rossum wrote:
>>
>> Did you study PEP 416 (frozendict) and PEP 603 (frozenmap)?
>
>
> Yes. About frozenmap, at the very start I added to the benchmarks also
> immutables.Map, but I removed it when
ays.
Yury
On Thu, Sep 12, 2019 at 12:46 PM Yury Selivanov wrote:
>
> Hi!
>
> I've just published a PEP to add a frozenmap type to Python; it should
> be online shortly.
>
> Read it here:
> https://discuss.python.org/t/pep-603-adding-a-frozenmap-type-to-collecti
#gistcomment-3020936
Yury
On Thu, Sep 12, 2019 at 3:52 PM Anders Hovmöller wrote:
>
>
>
> > On 12 Sep 2019, at 13:46, Yury Selivanov wrote:
> >
> > Hi!
> >
> > I've just published a PEP to add a frozenmap type to Python; it should
> > b
Hi!
I've just published a PEP to add a frozenmap type to Python; it should
be online shortly.
Read it here:
https://discuss.python.org/t/pep-603-adding-a-frozenmap-type-to-collections/2318
Here's an excerpt from the Abstract:
A *persistent data structure* is defined as a data structure that
pr
On Thu, Jun 6, 2019 at 5:20 PM Christoph Groth wrote:
[..]
> The other possibility I see would be wrapping ContextVar inside a class
> (like in the example module that I attached to the first post in this
> thread), but that's not a good solution. It requires replicating the
> complete API, and i
On Thu, Jun 6, 2019 at 8:04 AM Christoph Groth wrote:
>
> Yury Selivanov wrote:
>
> > I suggest you to open an issue on bugs.python.org to implement support
> > for context manager protocol for contextvars.Token. I'm not opposed
> > to the idea. Keep in mind
On Wed, Jun 5, 2019 at 6:22 PM Christoph Groth wrote:
[..]
> I'm aware of this possibility, however it is not suitable for the use
> case that I have in mind (configuration variables), because it requires
> too much code for each variable.
>
> Of course one could wrap your example inside a factory
Hi Christoph,
Adding context manager protocol support to contextvars.Token was
considered when PEP 567 was discussed. There wasn't a strong argument
against that; however we decided not to immediately add it because
context variables is a relatively low-level API. In you case, you can
simply wra
Yep, PEP 567 addresses this for coroutines, so David's first example
is covered; here's a link to the fixed version: [1]
The proposal to add __suspend__ and __resume__ is very similar to PEP
521 which was withdrawn. PEP 568 (which needs to be properly updated)
is the way to go if we want to addre
Thanks for proposing this. Yes, it makes sense to have
unittest.AsyncTestCase in 3.8. AFAIK Lisa Roach (copied) was working
on that (as well as on async Mock object), but I'm not sure what's the
status of her work. I suggest to search for an open issue for this on
bugs.python.org; if there's non
On Mon, Sep 17, 2018 at 4:16 PM James Lu wrote:
[..]
> So... we’re going to be using discourse instead of Python-ideas mailing list?
> Or will we only try that until Discourse works for “core sprints”?
Well, as I said: "If it works well we'll consider using it for other
discussions in the futur
It was decided to try https://www.discourse.org at the core dev
sprints. We'll likely try it for the upcoming governance model/vote
discussions. If it works well we'll consider using it for other
discussions in the future.
Let's table this topic for now as we're unlikely to
(a) try anything els
On Fri, Sep 7, 2018 at 12:31 AM Anders Hovmöller wrote:
>
> Yury,
>
> I’m sorry if that came off badly, I was not attempting to be snarky. Text is
> hard and I know I’m not good in emails but rereading the text below I
> honestly can’t see why my honest attempt at describing my experience can be
On Thu, Sep 6, 2018 at 10:57 PM Anders Hovmöller wrote:
[..]
> I don't think that's a good look for Python :P
Anders,
Discussing something privately with "a few people", posting snarky
conclusions, and giving baseless recommendations isn't how we strive
to make decisions in Python. Please refra
On Wed, Aug 8, 2018 at 12:28 PM Paul Moore wrote:
>
> On Wed, 8 Aug 2018 at 16:58, Oscar Benjamin
> wrote:
> > Thinking about this some more: closing() can ensure finalisation but
> > it is still generally bad to yield from a with block. Some context
> > managers are designed to temporarily alte
On Wed, Jun 20, 2018 at 6:34 AM Micheál Keane wrote:
[..]
> First, I couldn't find any real discussion about it after 2011 so I had no
> idea if the reasons it was ruled unfeasible with Python 2 still held nearly
> 10 years later with Python 3. I was mainly wondering if all the recent
> asynch
On Tue, Jun 12, 2018 at 5:34 AM Michel Desmoulin
wrote:
[..]
> But even if I have spoken up then, my experience with Python-idea is
that most of the time, people would have told me "no". They would have
told me that "nobody is going to do that".
> I'm getting used to it. It took me a lot of time
ote:
>>
>> In my mind aiohttp doesn't depend on
>>
>> On Mon, Jun 11, 2018, 19:24 Yury Selivanov wrote:
>>>
>>> > I want to abstract that from the user, so I tried to put that in a
>>> policy. But that's dangerous since it can be chan
> I want to abstract that from the user, so I tried to put that in a
policy. But that's dangerous since it can be changed at any time, so I
gave up on it and made it explicit. Of course, if the user misses that
in the doc (hopefully, it's an company internal code so they should be
trained), it will
Hi Michel,
Yes, theoretically, it's possible to try to change an event loop
policy while an event loop is running, but I've yet to see a library
(or user code) that tries to do that (it's pointless anyways). There
are libraries like uvloop that tell their users to explicitly install
a special poli
On Tue, May 22, 2018 at 2:09 PM Terry Reedy wrote:
[..]
> I like the idea of making coroutines easier and use. It would make more
> sense to me to expose an eventloop class as a builtin, so that one would
> write
> eventloop().run_until_complete(hello)
> eventloop would not necessarily have to
On Sat, Apr 28, 2018 at 2:07 AM Tim Peters wrote:
[...]
> Speaking of which, "sublocal" would be a more accurate name, and less
> likely to conflict with existing code names, but after people got over
> the shock to their sense of purity, they'd appreciate typing the
> shorter "local" instead ;-)
Hi Tim,
This is interesting. Even "as is" I prefer this to PEP 572. Below are some
comments and a slightly different idea inspired by yours (sorry!)
On Fri, Apr 27, 2018 at 10:41 PM Tim Peters wrote:
[..]
> As an expression, it's
> "local" "(" arguments ")"
> - Because it "looks like" a f
On Thu, Feb 1, 2018 at 12:55 PM, Brett Cannon wrote:
>
>
> On Thu, 1 Feb 2018 at 07:34 Pau Freixes wrote:
[..]
>> 2) Regarding the Yuris proposal to cache bultin functions, why this
>> strategy cant be used for objects and their attributes within the function
>> scope? Technically which is the re
On Mon, Dec 11, 2017 at 6:21 PM, Franklin? Lee
wrote:
> What about hanging onto just the value, and creating new StopIteration
> instances instead of raising the same one again?
Doesn't really matter, as we're still prolonging the lifespan of the
returned object.
To me the current behaviour of g
On Sun, Oct 15, 2017 at 8:15 AM, Paul Moore wrote:
> On 13 October 2017 at 23:30, Yury Selivanov wrote:
>> At this point of time, there's just one place which describes one well
>> defined semantics: PEP 550 latest version. Paul, if you have
>> time/interest, please
On Fri, Oct 13, 2017 at 4:29 PM, Paul Moore wrote:
[..]
> Nick's other async refactoring example is different. If the two forms
> he showed don't behave identically in all contexts, then I'd consider
> that to be a major problem. Saying that "coroutines are special" just
> reads to me as "coroutin
On Fri, Oct 13, 2017 at 1:46 PM, Koos Zevenhoven wrote:
> On Fri, Oct 13, 2017 at 7:38 PM, Yury Selivanov
> wrote:
>>
>> On Fri, Oct 13, 2017 at 11:49 AM, Koos Zevenhoven
>> wrote:
>> [..]
>> > This was my starting point 2.5 years ago, when Yury was draf
On Fri, Oct 13, 2017 at 1:45 PM, Ethan Furman wrote:
> On 10/13/2017 09:48 AM, Steve Dower wrote:
>>
>> On 13Oct2017 0941, Yury Selivanov wrote:
>
>
>>> Actually, capturing context at the moment of coroutine creation (in
>>> PEP 550 v1 semantics) will n
On Fri, Oct 13, 2017 at 3:25 AM, Nick Coghlan wrote:
[..]
> However, considering that coroutines are almost always instantiated at the
> point where they're awaited, I do concede that creation time context capture
> would likely also work out OK for the coroutine case, which would leave
> contextl
On Fri, Oct 13, 2017 at 11:49 AM, Koos Zevenhoven wrote:
[..]
> This was my starting point 2.5 years ago, when Yury was drafting this status
> quo (PEP 492). It looked a lot of PEP 492 was inevitable, but that there
> will be a problem, where each API that uses "blocking IO" somewhere under
> the
On Fri, Oct 13, 2017 at 3:25 AM, Nick Coghlan wrote:
[..]
> The rationale for this behaviour *does* arise from a refactoring argument:
>
>async def original_async_function():
> with some_context():
> do_some_setup()
> raw_data = await some_operation()
>
> Although it is true that I plan to propose to use PEP 550 to
> reimplement decimal APIs on top of it, and so far I haven't seen any
> real-world examples of code that will be broken because of that. As
> far as I know—and I've done some research—nobody uses decimal contexts
>
> and generators be
On Thu, Oct 12, 2017 at 8:59 AM, Koos Zevenhoven wrote:
> On Thu, Oct 12, 2017 at 6:54 AM, Nick Coghlan wrote:
[..]
>> 1. Preserve the current behaviour, since we don't have a compelling reason
>> to change its semantics
>> 2. Change the behaviour, in order to gain
>>
>
> 3. Introduce a new cont
On Tue, Oct 10, 2017 at 12:34 PM, Koos Zevenhoven wrote:
> On Tue, Oct 10, 2017 at 3:42 PM, Nick Coghlan wrote:
[..]
>> Context managers are merely syntactic sugar for try/finally statements, so
>> you can't wave your hands and say a context manager is the only supported
>> API: you *have* to bre
On Tue, Oct 10, 2017 at 12:21 PM, Koos Zevenhoven wrote:
[..]
>> Please stop using "many things .. would", "most likely" etc.
>
>
> I can't explain everything, especially not in a single email. I will use
> whatever English words I need. You can also think for yourself––or ask a
> question.
I can
On Tue, Oct 10, 2017 at 11:26 AM, Koos Zevenhoven wrote:
> On Tue, Oct 10, 2017 at 5:40 PM, Yury Selivanov
> wrote:
>>
>> On Tue, Oct 10, 2017 at 8:34 AM, Koos Zevenhoven
>> wrote:
>> > On Tue, Oct 10, 2017 at 4:22 AM, Yury Selivanov
>> >
>> >
On Tue, Oct 10, 2017 at 10:22 AM, Koos Zevenhoven wrote:
> On Tue, Oct 10, 2017 at 5:01 PM, Nick Coghlan wrote:
>>
>> On 10 October 2017 at 22:51, Koos Zevenhoven wrote:
>>>
>>> I see no reason why these two should be equivalent.
>>
>>
>> There is no "should" about it: it's a brute fact that the
On Tue, Oct 10, 2017 at 8:34 AM, Koos Zevenhoven wrote:
> On Tue, Oct 10, 2017 at 4:22 AM, Yury Selivanov
> wrote:
>>
>> On Mon, Oct 9, 2017 at 8:37 PM, Koos Zevenhoven wrote:
>> > You can cause unbound growth in PEP 550 too. All you have to do is nest
>&
On Mon, Oct 9, 2017 at 8:37 PM, Koos Zevenhoven wrote:
[..]
>> Another thing: suppose someone calls
>> 'context_var.assign().__enter__()' manually, without calling
>> '__exit__()'. You will have unbound growth of the context values
>> stack.
>
>
> You can cause unbound growth in PEP 550 too. All
On Mon, Oct 9, 2017 at 4:39 PM, Koos Zevenhoven wrote:
> On Mon, Oct 9, 2017 at 6:24 PM, Guido van Rossum wrote:
[..]
>> I'm not sure I agree on the usefulness. Certainly a lot of the complexity
>> of PEP 550 exists just to cater to Nathaniel's desire to influence what a
>> generator sees via the
On Mon, Sep 11, 2017 at 3:25 PM, Lukasz Langa wrote:
[..]
> This PEP is proposing delaying evaluation until annotations are accessed but
> gives user code the power to decide whether the string form is enough, or
> maybe an AST would be enough, or actual evaluation with get_type_hints() or
> eval(
On Tue, Sep 5, 2017 at 10:31 AM, Koos Zevenhoven wrote:
> On Tue, Sep 5, 2017 at 8:24 PM, Yury Selivanov
> wrote:
>>
>> On Tue, Sep 5, 2017 at 9:12 AM, Koos Zevenhoven wrote:
>> > On Tue, Sep 5, 2017 at 6:53 PM, Yury Selivanov
>> > wrote:
>> >
On Tue, Sep 5, 2017 at 9:12 AM, Koos Zevenhoven wrote:
> On Tue, Sep 5, 2017 at 6:53 PM, Yury Selivanov
> wrote:
>>
>> On Tue, Sep 5, 2017 at 8:35 AM, Koos Zevenhoven wrote:
>> > On Tue, Sep 5, 2017 at 3:49 AM, Nathaniel Smith wrote:
>> [..]
>> >>
On Tue, Sep 5, 2017 at 8:35 AM, Koos Zevenhoven wrote:
> On Tue, Sep 5, 2017 at 3:49 AM, Nathaniel Smith wrote:
[..]
>>
>> I think PEP 550 is sufficient to allow implementing all
>> your proposed APIs (and that if it isn't, that's a bug in PEP 550).
>
>
> That's not true either. The LocalContext-
We'll add a reference to the "Can Execution Context be implemented
without modifying CPython?" section [1].
However, after skimming through the readme file, I didn't see any
examples or limitations that are relevant to PEP 550. If the PEP gets
accepted, Twisted can simply add direct support for i
So every generator stores "captured" modifications. This is similar
to PEP 550, which adds Logical Context to generators to store their EC
modifications. The implementation is different, but the intent is the
same.
PEP 550 uses a stack of hash tables, this proposal has a linked list
of Assignment
There's another "major" problem with theading.local()-like API for PEP
550: C API.
threading.local() in C right now is PyThreadState_GetDict(), which
returns a dictionary for the current thread, that can be
queried/modified with PyDict_* functions. For PEP 550 this would not
work.
The advantage
Hi Jim,
In short, yes, we can "dumb down" PEP 550 to a chain of maps.
PEP 550 does the following on top of that dumbed down version:
0. Adds execution_context "chain" root to PyThreadState.
1. Extends (async-)generator objects to support this chaining -- each
generator has its own "env" to accu
On Fri, Aug 18, 2017 at 1:09 AM, Nick Coghlan wrote:
> On 17 August 2017 at 01:22, Yury Selivanov wrote:
>> On Wed, Aug 16, 2017 at 4:07 AM, Nick Coghlan wrote:
>>>> Coroutine Object Modifications
>>>> ^^
>>>>
>>>
On Fri, Aug 18, 2017 at 2:12 AM, Stefan Behnel wrote:
> Nathaniel Smith schrieb am 16.08.2017 um 09:18:
>> On Tue, Aug 15, 2017 at 4:55 PM, Yury Selivanov wrote:
>>> Here's the PEP 550 version 2.
>> Awesome!
>
> +1
>
>>> Backwards Compatibility
&g
On Wed, Aug 16, 2017 at 12:55 PM, Yury Selivanov
[..]
> And immediately after I hit "send" I realized that this is a bit more
> complicated.
>
> In order for Tasks to remember the full execution context of where
> they were created, we need a new method that would allow
On Wed, Aug 16, 2017 at 4:12 PM, Antoine Pitrou wrote:
>
>
> Hi,
>
>> * ``sys.get_execution_context()`` function. The function returns a
>> copy of the current EC: an ``ExecutionContext`` instance.
>
> Can you explain the requirement for it being a copy?
When the execution context is used to s
On Wed, Aug 16, 2017 at 1:13 PM, Stefan Krah wrote:
> On Wed, Aug 16, 2017 at 12:40:26PM -0400, Yury Selivanov wrote:
>> On Wed, Aug 16, 2017 at 12:08 PM, Stefan Krah wrote:
>> > On Wed, Aug 16, 2017 at 11:00:43AM -0400, Yury Selivanov wrote:
>> >> "Context&q
On Wed, Aug 16, 2017 at 12:51 PM, Yury Selivanov
wrote:
> On Wed, Aug 16, 2017 at 5:36 AM, Nick Coghlan wrote:
>> On 16 August 2017 at 17:18, Nathaniel Smith wrote:
>> [Yury wrote]
> [..]
>>>> * If ``coro.cr_local_context`` is an empty ``LocalContext`` obj
On Wed, Aug 16, 2017 at 5:36 AM, Nick Coghlan wrote:
> On 16 August 2017 at 17:18, Nathaniel Smith wrote:
> [Yury wrote]
[..]
>>> * If ``coro.cr_local_context`` is an empty ``LocalContext`` object
>>> that ``coro`` was created with, the interpreter will set
>>> ``coro.cr_local_context``
On Wed, Aug 16, 2017 at 12:08 PM, Stefan Krah wrote:
> On Wed, Aug 16, 2017 at 11:00:43AM -0400, Yury Selivanov wrote:
>> "Context" is an established term for what PEP 550 tries to accomplish.
>> It's used in multiple languages and runtimes, and while research
On Wed, Aug 16, 2017 at 3:18 AM, Nathaniel Smith wrote:
> On Tue, Aug 15, 2017 at 4:55 PM, Yury Selivanov
> wrote:
>> Hi,
>>
>> Here's the PEP 550 version 2.
>
> Awesome!
Thanks!
[..]
>>
>> * **Local Context**, or LC, is a key/value mapping t
On Wed, Aug 16, 2017 at 11:03 AM, Nick Coghlan wrote:
> On 17 August 2017 at 00:25, Stefan Krah wrote:
>> Perhaps it would be possible to name the data structures by their
>> functionality.
>> E.g. if ExecutionContext is a stack, use ExecutionStack?
>>
>> Or if the dynamic scope angle should be
t".
>
> On 16 August 2017 at 09:55, Yury Selivanov wrote:
>> Context Item Object
>> ---
>>
>> The ``sys.new_context_item(description)`` function creates a
>> new ``ContextItem`` object. The ``description`` parameter is a
>> ``str``, ex
On Wed, Aug 16, 2017 at 10:25 AM, Stefan Krah wrote:
> On Wed, Aug 16, 2017 at 12:18:23AM -0700, Nathaniel Smith wrote:
>> > Here's the PEP 550 version 2.
>>
>> Awesome!
>>
>> Some of the changes from v1 to v2 might be a bit confusing -- in
>> particular the thing where ExecutionContext is now a s
On Wed, Aug 16, 2017 at 2:53 AM, Jelle Zijlstra
wrote:
[..]
>>
>> The below is an example of how context items can be used::
>>
>> my_context = sys.new_context_item(description='mylib.context')
>> my_context.set('spam')
>
>
> Minor suggestion: Could we allow something like
> `sys.set_new_c
ssing values in the context is even faster now.
Thank you!
PEP: 550
Title: Execution Context
Version: $Revision$
Last-Modified: $Date$
Author: Yury Selivanov
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Aug-2017
Python-Version: 3.7
Post-History: 11-Aug-2017, 15-Aug-
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
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
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
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
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
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 co
>> 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
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
[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
&g
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
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/
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
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
> 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
[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
Title: Execution Context
Version: $Revision$
Last-Modified: $Date$
Author: Yury Selivanov
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Aug-2017
Python-Version: 3.7
Post-History: 11-Aug-2017
Abstract
This PEP proposes a new mechanism to manage execution state
TBH I think that optional parameters isn't a problem requiring new
syntax. We probably do need syntax for positional-only arguments
(since we already have them in a way), but optional parameters
can be solved easily without a new syntax.
Syntax like:
1. def a(?foo),
2. def a(foo=pass),
3. def a
I'm +0.5 to add positional-only parameters.
Pros:
* A lot of people don't know what '/' currently means in
functions signatures rendered by `help` and docs. Because
it's not a real syntax, it's really hard to find what it
means.
* Some APIs do look better with positional-only parameters,
espec
On 2017-01-31 10:57 AM, Joao S. O. Bueno wrote:
BUT - no, it is_not_ an easy decorator to craft - and I don't think
it can be made to work
cleanly without depending on implementation details of cPython.
Pure Python version is certainly possible with descriptor protocol.
PoC: https://gist.gith
This is a neat idea, but this will only work for parsing framed
binary protocols. For example, if you protocol prefixes all packets
with a length field, you can write an efficient read buffer and
use your proposal to decode all of message's fields in one shot.
Which is good.
Not all protocols us
I actually thought about adding 'Exception.__hint__' attribute which
would have a longer message explaining what happened and how to fix it.
displayhooks can be easily modified to print __hint__ when it's set. We
can then add C API to set hints.
To address any possible performance concerns,
On 2016-11-14 1:35 PM, Sven R. Kunze wrote:
What about making "run" an instance method of coroutines?
That would require coroutines to be aware of the loop that is running
them. Not having them aware of that is what makes the design simple and
allows alternatives to asyncio.
All in all
Hi Guido,
On 2016-11-12 4:24 PM, Guido van Rossum wrote:
I think there's a plan to add a run() function to asyncio, which would be
something akin to
def run(coro):
return get_event_loop().run_until_complete(coro)
(but perhaps with better cleanup).
Please see https://github.com/python/a
On 2016-10-25 4:33 AM, Nick Coghlan wrote:
I'm starting to think that we instead need a way
to let them easily say "This resource, the one I just created or have
otherwise gained access to? Link its management to the lifecycle of
the currently running function or frame, so it gets cleaned up wh
iated resources from the
outside of the generator (i.e. don't put 'async with' or 'with'
inside the generator's body; instead, wrap the code that uses
the generator with 'async with' or 'with').
Yury
On 21 October 2016 at 16:08, Yury Selivanov wr
On 2016-10-21 7:13 AM, Steven D'Aprano wrote:
Consistency is over-rated, and we already have inconsistency
here: file iterators behave differently from list iterators, because
they can be closed:
This is **very** arguable :)
Yury
___
Python-ideas m
1 - 100 of 125 matches
Mail list logo
