really like what Paul Moore wrote here as it matches a *LOT* of what I
have been feeling as I have been reading this whole discussion;
specifically:
- I find the example, and discussion, really hard to follow.
- I also, don't understand async, but I do understand generators very
On 10/13/2017 03:30 PM, Yury Selivanov wrote:
At this time, we have so many conflicted examples and tangled
discussions on these topics, that I myself just lost what everybody is
implying by "this semantics isn't obvious to *me*". Which semantics?
It's hard to tell.
For me, it's not apparent
On Fri, Oct 13, 2017 at 11:35 AM, Chris Angelico wrote:
> On Sat, Oct 14, 2017 at 5:16 AM, Antoine Rozo
> wrote:
> [...]
> Can we consider making itertools a package and adding a module
> > itertools.recipes that implements all these utilility
On 13Oct2017 1132, Yury Selivanov wrote:
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)
On 13 October 2017 at 19:32, Yury Selivanov wrote:
>>> It seems simpler to have one specially named and specially called function
>>> be special, rather than make the semantics
>>> more complicated for all functions.
>>
>
> It's not possible to special case __aenter__ and
On Sat, Oct 14, 2017 at 5:16 AM, Antoine Rozo wrote:
> Hello,
>
> A very useful part of the itertools module's documentation is the section
> "Recipes", giving utility functions that use itertools iterators.
> But when you want to use one of theese functions, you have to
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 not work at all. Async
Hello,
A very useful part of the itertools module's documentation is the section
"Recipes", giving utility functions that use itertools iterators.
But when you want to use one of theese functions, you have to copy it in
your source code (or use external PyPI modules like iterutils).
Can we
On Fri, Oct 13, 2017 at 8: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 not work at all. Async
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 drafting this
> status
> > quo (PEP 492). It looked a lot of PEP 492
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 not work at all. Async context managers
will break.
class AC:
async def __aenter__(self):
On Fri, Oct 13, 2017 at 2:07 AM, Stefan Krah wrote:
[..]
> So the decimal examples can be helpful for understanding, but (except
> for the performance issues) shouldn't be the centerpiece of the
> discussion.
>
>
> Speaking of performance, I have seen that adressed in Koos'
On 13Oct2017 0941, Yury Selivanov wrote:
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
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
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"
This is a continuation of the PEP 555 discussion in
https://mail.python.org/pipermail/python-ideas/2017-September/046916.html
And this month in
https://mail.python.org/pipermail/python-ideas/2017-October/047279.html
If you are new to the discussion, the best point to start reading this
might
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
On Fri, 13 Oct 2017 16:57:28 +0200
Stefan Behnel wrote:
> Victor Stinner schrieb am 13.10.2017 um 16:12:
> > I would like to add new functions to return time as a number of
> > nanosecond (Python int), especially time.time_ns().
>
> I might have missed it while skipping
2017-10-13 16:57 GMT+02:00 Stefan Behnel :
> I might have missed it while skipping through your post, but could you
> quickly explain why improving the precision of time.time() itself wouldn't
> help already? Would double FP precision not be accurate enough here?
80-bit
Victor Stinner schrieb am 13.10.2017 um 16:12:
> I would like to add new functions to return time as a number of
> nanosecond (Python int), especially time.time_ns().
I might have missed it while skipping through your post, but could you
quickly explain why improving the precision of time.time()
Hi,
I would like to add new functions to return time as a number of
nanosecond (Python int), especially time.time_ns().
It would enhance the time.time() clock resolution. In my experience,
it decreases the minimum non-zero delta between two clock by 3 times,
new "ns" clock versus current clock:
On 13 October 2017 at 10:56, Guido van Rossum wrote:
> I'm out of energy to debate every point (Steve said it well -- that
> decimal/generator example is too contrived), but I found one nit in Nick's
> email that I wish to correct.
>
> On Wed, Oct 11, 2017 at 1:28 AM, Nick
22 matches
Mail list logo