Changes by Yury Selivanov yseliva...@gmail.com:
--
dependencies: +Awaitable ABC incompatible with functools.singledispatch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Stefan Behnel added the comment:
See issue 24400 regarding a split of yield-based generators and async-def
coroutines at a type level.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
Yury Selivanov added the comment:
Guido, Stefen, please see issue24383.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Yury Selivanov added the comment:
Hmm, but IMHO a) the new syntax isn't just for asyncio and b) awaiting a
Future seems like a *very* reasonable thing to do. I think opening a new
ticket for this is a good idea.
Stefan, I honestly have bo idea what concurrent.Future.__await__ would do.
Alex Grönholm added the comment:
Was __await__() deliberately left out of concurrent.futures.Future or was that
an oversight? Or am I misunderstanding something?
--
nosy: +alex.gronholm
___
Python tracker rep...@bugs.python.org
Yury Selivanov added the comment:
Was __await__() deliberately left out of concurrent.futures.Future or was
that an oversight? Or am I misunderstanding something?
I don't think concurrent.Future is supposed to be used with asyncio (in 'yield
from' or 'await' expressions).
--
Roundup Robot added the comment:
New changeset 1e9e0664ee9b by Yury Selivanov in branch '3.5':
Issue 24017: Make PyEval_(Set|Get)CoroutineWrapper private
https://hg.python.org/cpython/rev/1e9e0664ee9b
New changeset 6fcb64097b1c by Yury Selivanov in branch 'default':
Issue 24017: Make
Roundup Robot added the comment:
New changeset a0a699b828e7 by Yury Selivanov in branch '3.5':
Issue 24017: Add a test for CoroWrapper and 'async def' coroutines
https://hg.python.org/cpython/rev/a0a699b828e7
New changeset 89521ac669f0 by Yury Selivanov in branch 'default':
Issue 24017: Add a
Roundup Robot added the comment:
New changeset 0708aabefb55 by Yury Selivanov in branch '3.4':
Issue 24017: Fix asyncio.CoroWrapper to support 'async def' coroutines
https://hg.python.org/cpython/rev/0708aabefb55
New changeset 1dc232783012 by Yury Selivanov in branch '3.5':
Issue 24017: Fix
Yury Selivanov added the comment:
Stefan,
Because of
https://mail.python.org/pipermail/python-committers/2015-May/003410.html I've
decided to commit 24315 and 24316 today. Please try to check that everything
works before new beta 2.
--
___
Yury Selivanov added the comment:
Tried it, works for me. Thanks!
This is really good news! Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Stefan Behnel added the comment:
Tried it, works for me. Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Python-bugs-list
Stefan Behnel added the comment:
Yield-from iterates, and a coroutine is not supposed to be iterable, only
awaitable (at least, that's what all error messages tell me when I try it).
So why should yield from work on them? What if foo() was not an Iterable
but a Coroutine? Should yield
Stefan Behnel added the comment:
BTW, given that iter(iterator) works and returns the iterator, should we also
allow await x.__await__() to work? I guess that would be tricky to achieve
given that __await__() is only required to return any kind of arbitrary
Iterator, and Iterators cannot be
Stefan Behnel added the comment:
Can't your Coroutine object return itself from its __await__, and implement
__next__? Like genobject in CPython simply returns self from its __iter__.
That was my first try, sure, and it mostly worked. It has a drawback,
though: it's an incomplete
Roundup Robot added the comment:
New changeset dfa0288c91fd by Yury Selivanov in branch '3.5':
Issue 24017: Drop getawaitablefunc and friends in favor of unaryfunc.
https://hg.python.org/cpython/rev/dfa0288c91fd
New changeset 99dcca3466d3 by Yury Selivanov in branch 'default':
Issue 24017: Drop
Roundup Robot added the comment:
New changeset 09327f653ec5 by Yury Selivanov in branch '3.4':
asyncio: Drop some useless code from tasks.py.
https://hg.python.org/cpython/rev/09327f653ec5
New changeset adf72cffceb7 by Yury Selivanov in branch '3.5':
asyncio: Drop some useless code from
Changes by Yury Selivanov yseliva...@gmail.com:
--
dependencies: +collections.abc: Coroutine should be derived from Awaitable
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Yury Selivanov added the comment:
Stefan,
I've already committed fixes for:
1. getawaitablefunc / aiternextfunc / getaiterfunc - unaryfunc
2. strange code in tasks.py doing coro = iter(coro) is now removed
I've also opened a couple of new issues (with patches for a review):
1.
Stefan Behnel added the comment:
Thanks Yury, I'll give it a try ASAP.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Roundup Robot added the comment:
New changeset 843fe7e831a8 by Yury Selivanov in branch '3.5':
Issue 24297: Update symbol.py. See also issue 24017.
https://hg.python.org/cpython/rev/843fe7e831a8
New changeset 87509d71653b by Yury Selivanov in branch 'default':
Issue 24297: Update symbol.py. See
Stefan Behnel added the comment:
It *is* correct, see PEP 492. Awaitable is either a coroutine *or* an object
with an __await__ method.
coroutine, yes. But Coroutine? Shouldn't the Coroutine ABC then require
__await__ to be implemented? Maybe even by inheriting from Awaitable?
Just
Nick Coghlan added the comment:
Thanks for highlighting these Stefan - you guessed correctly that I'd missed
them on the review.
For your first question, I agree getawaitablefunc / aiternextfunc /
getaiterfunc should all be dropped and replaced with the existing unaryfunc.
For your second
Nick Coghlan added the comment:
Given that tp_call is just ternaryfunc, my guess would be because when the
iterator protocol was added, someone went with function-pointer-type-per-slot
rather than function-pointer-type-per-call-signature.
We *are* a little inconsistent here (e.g. reprfunc
Yury Selivanov added the comment:
It *is* correct, see PEP 492. Awaitable is either a coroutine *or* an
object with an __await__
method.
coroutine, yes. But Coroutine? Shouldn't the Coroutine ABC then require
__await__ to be implemented? Maybe even by inheriting from Awaitable?
This
Yury Selivanov added the comment:
For your first question, I agree getawaitablefunc / aiternextfunc /
getaiterfunc should all be dropped and replaced with the existing unaryfunc.
I have no problem with that. But why do we have iternextfunc getiterfunc (no
a prefix)?
--
Stefan Behnel added the comment:
I added a couple of review comments to patch 6, but since no-one has responded
so far, I guess they simply haven't been noticed. So I'll just repeat them here.
1)
getawaitablefunc / aiternextfunc / getaiterfunc
Is there a reason why these need to have their
Yury Selivanov added the comment:
2) Awaitable.register(Coroutine)
I think this is incorrect. A Coroutine is not Awaitable unless it also
implements __await__. How else should it be awaited?
It *is* correct, see PEP 492. Awaitable is either a coroutine *or* an object
with an __await__
Stefan Behnel added the comment:
Another question: is it ok if Cython implements and uses the tp_as_async slot
in all Py3.x versions (3.2+)? It shouldn't hurt, but it would speed up
async/await in Cython at least under Py3.x. Only Py2.6/7 would then have to
resort to calling __await__() etc.
Roundup Robot added the comment:
New changeset ff983ee10b3e by Yury Selivanov in branch 'default':
Issue 24017: Use abc.Coroutine in inspect.iscoroutine() function
https://hg.python.org/cpython/rev/ff983ee10b3e
--
___
Python tracker
Yury Selivanov added the comment:
Closing the issue. I'll open a new one for missing documentation. Thanks!
--
components: +Interpreter Core
resolution: - fixed
stage: patch review - resolved
status: open - closed
___
Python tracker
Changes by Yury Selivanov yseliva...@gmail.com:
--
dependencies: +PEP 492: Documentation
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Roundup Robot added the comment:
New changeset 0d80d46adfdb by Yury Selivanov in branch 'default':
Issue 24017: More tests for 'async for' and 'async with'.
https://hg.python.org/cpython/rev/0d80d46adfdb
--
___
Python tracker rep...@bugs.python.org
Guido van Rossum added the comment:
BTW, a shout out to Nick for doing most of the review for this monster patch.
Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Changes by Yury Selivanov yseliva...@gmail.com:
--
dependencies: +PEP 492: Add AsyncIterator and AsyncIterable to collections.abc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Nick Coghlan added the comment:
A bit more detail on the patch-as-merged: it has all of Yury's new tests, but
the actual bug turned out to just be a missing INCREF/DECREF pair in
WITH_CLEANUP_START and WITH_CLEANUP_FINISH.
In the success case the reference counting errors cancelled each other
Roundup Robot added the comment:
New changeset 9d2c4d887c19 by Yury Selivanov in branch 'default':
Issue #24017: Unset asyncio event loop after test.
https://hg.python.org/cpython/rev/9d2c4d887c19
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset e39fd5a8501a by Nick Coghlan in branch 'default':
Issue 24017: fix for async with refcounting
https://hg.python.org/cpython/rev/e39fd5a8501a
--
___
Python tracker rep...@bugs.python.org
Yury Selivanov added the comment:
Is there are a specific reason this implicit exception handler can't be
decomposed and implemented using the same opcodes as are used to implement
explicit exception handlers?
I don't think it's possible to replace ASYNC_WITH_CLEANUP_EXCEPT opcode with
Nick Coghlan added the comment:
I'm going to dig into this one locally, as it sounds to me like something may
be going wrong with the refcounts in the complex stack manipulation involved in
WITH_CLEANUP. It seems plausible that there's a genuinely missing incref/decref
pair somewhere in the
Yury Selivanov added the comment:
I'd suggest you to look at ceval.c before PEP 492 patch then (where there is
just one WITH_CLEANUP opcode).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
Nick Coghlan added the comment:
Avoiding WITH_CLEANUP entirely in the async case also sounds like a plausible
approach. Either way, I'm also on IRC now if you want to thrash this out there.
--
___
Python tracker rep...@bugs.python.org
Yury Selivanov added the comment:
Nick, Guido,
Attached is a patch that fixes a refleak in 'async with' implementation.
The problem is related to WITH_CLEANUP_START/WITH_CLEANUP_FINISH opcodes.
For regular 'with' statements, these opcodes go one after another (essentially,
it was one opcode
Nick Coghlan added the comment:
I'm bothered by the remarkable proliferation of new opcodes for the PEP 492
handling. Is there are a specific reason this implicit exception handler can't
be decomposed and implemented using the same opcodes as are used to implement
explicit exception handlers?
Roundup Robot added the comment:
New changeset 0dc3b61f1dfa by Yury Selivanov in branch 'default':
Issue #24017: Plug ref leak.
https://hg.python.org/cpython/rev/0dc3b61f1dfa
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset ee7d2c9c70ab by Yury Selivanov in branch '3.4':
asyncio: Make sure sys.set_coroutine_wrapper is called *only* when loop is
running.
https://hg.python.org/cpython/rev/ee7d2c9c70ab
New changeset 874edaa34b54 by Yury Selivanov in branch 'default':
Yury Selivanov added the comment:
Nick, Guido,
Updated patch attached.
--
Added file: http://bugs.python.org/file39344/await_06.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Nick Coghlan added the comment:
Guido convinced me that having StopAsyncIteration inherit from Exception was
the right approach, as it means errors are more likely to be of the we caught
it when we shouldn't have variety, rather than the harder to debug an
exception escaped when it shouldn't
Roundup Robot added the comment:
New changeset 3a3cc2b9a1b2 by Yury Selivanov in branch 'default':
Issue 24017: Update NEWS file.
https://hg.python.org/cpython/rev/3a3cc2b9a1b2
--
___
Python tracker rep...@bugs.python.org
Nick Coghlan added the comment:
Latest version looks good to me (aside from a quibble about whether
StopAsyncIteration should inherit from BaseException instead of Exception - see
my review for details).
Based on Guido's explanation in the review, I also suggested adding the
following
Roundup Robot added the comment:
New changeset 957478e95b26 by Yury Selivanov in branch '3.4':
asyncio: Support PEP 492. Issue #24017.
https://hg.python.org/cpython/rev/957478e95b26
New changeset 44c1db190525 by Yury Selivanov in branch 'default':
asyncio: Merge 3.4 -- Support PEP 492. Issue
Yury Selivanov added the comment:
Guido, Nick, Victor,
Thanks for your reviews and guidance! The patch has been committed to the
default branch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
Roundup Robot added the comment:
New changeset eeeb666a5365 by Yury Selivanov in branch 'default':
PEP 0492 -- Coroutines with async and await syntax. Issue #24017.
https://hg.python.org/cpython/rev/eeeb666a5365
--
___
Python tracker
Guido van Rossum added the comment:
Thank you Yury! You are a coding machine.
On Mon, May 11, 2015 at 8:06 PM, Yury Selivanov rep...@bugs.python.org
wrote:
Yury Selivanov added the comment:
Guido, Nick, Victor,
Thanks for your reviews and guidance! The patch has been committed to the
Changes by Yury Selivanov yseliva...@gmail.com:
--
dependencies: +add a Generator ABC
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Yury Selivanov added the comment:
New patch is attached.
Nick, I think that all of your feedback should be addressed in this patch.
Major changes:
1. There are two code flags now: CO_COROUTINE and CO_GENBASED_COROUTINE (I'm OK
to use another name, see my older comments). CO_COROUTINE is
Andrew Svetlov added the comment:
On Sun, May 10, 2015 at 7:21 PM, Yury Selivanov rep...@bugs.python.org wrote:
Yury Selivanov added the comment:
Review sent - very nice work on this Yury.
Thanks a lot, Nick!
Highlights:
* I concur with Stefan that we should have a full
Yury Selivanov added the comment:
Review sent - very nice work on this Yury.
Thanks a lot, Nick!
Highlights:
* I concur with Stefan that we should have a full PyCoroutineMethods struct
at the C level, with a tp_as_coroutine pointer to that replacing the
current tp_reserved slot
Do you
Nick Coghlan added the comment:
Review sent - very nice work on this Yury.
Highlights:
* I concur with Stefan that we should have a full PyCoroutineMethods struct at
the C level, with a tp_as_coroutine pointer to that replacing the current
tp_reserved slot
* I also concur with Stefan about
Yury Selivanov added the comment:
Another iteration:
- support of new syntax in lib2to3
- collections.abc.Awaitable
--
Added file: http://bugs.python.org/file39325/await_04.patch
___
Python tracker rep...@bugs.python.org
Stefan Behnel added the comment:
We also need a Coroutine ABC. Both the GeneratorType and CO_COROUTINE
checks are too restrictive. Also see issue 24018, which this one should in fact
depend on.
--
___
Python tracker rep...@bugs.python.org
Yury Selivanov added the comment:
Third patch attached. Victor, it would be great if you can review it!
--
Added file: http://bugs.python.org/file39314/await_03.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
Changes by Yury Selivanov yseliva...@gmail.com:
--
dependencies: +Missing *-unpacking generalizations
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Changes by Yury Selivanov yseliva...@gmail.com:
--
priority: normal - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Yury Selivanov added the comment:
I'll upload the most recent patch soon.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Guido van Rossum added the comment:
I think we can continue this discussion *after* the PEP's been accepted.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Stefan Behnel added the comment:
I don't think it's necessary to have slots for __aiter__, __anext__,
__aenter__ and __aexit__. Async iteration will never be as fast as regular
iteration, and there is plenty overhead in it.
You seem to be assuming that the outer loop is the asyncio I/O
Changes by Guido van Rossum gu...@python.org:
--
nosy: +gvanrossum
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Python-bugs-list
Stefan Behnel added the comment:
Could we have type slots for the new special methods? Otherwise, implementing
the protocol in C would be fairly inefficient, especially for async iteration.
I'm asking because Cython's generator type is not Python's generator type, but
implementing the rest of
Yury Selivanov added the comment:
In fact I will likely add tp_await in the next PEP iteration. I need it to
implement another feature.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
Yury Selivanov added the comment:
Could we have type slots for the new special methods? Otherwise, implementing
the protocol in C would be fairly inefficient, especially for async iteration.
I don't think it's necessary to have slots for __aiter__, __anext__, __aenter__
and __aexit__.
Changes by Yury Selivanov yseliva...@gmail.com:
--
dependencies: +PEP 479: Change StopIteration handling inside generators
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
STINNER Victor added the comment:
Does the implementation depends on the implementation of the PEP 479? (issue
#22906)
Attaching a patch generated with mercurial
Next time, if possible, try to skip generated files. Maybe write a script for
that, but sorry I don't know how :-(
--
Changes by Yury Selivanov yseliva...@gmail.com:
--
assignee: - yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Yury Selivanov added the comment:
Attaching a revised patch (all Victor's comments but asyncio changes)
--
Added file: http://bugs.python.org/file39155/await_02.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
Changes by Stefan Behnel sco...@users.sourceforge.net:
--
nosy: +scoder
type: - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Changes by STINNER Victor victor.stin...@gmail.com:
--
hgrepos: -306
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Python-bugs-list
New submission from Yury Selivanov:
Here's the first patch (git diff master..await). Should be easier to review and
work from there.
--
keywords: +patch
stage: - patch review
Added file: http://bugs.python.org/file39147/async_01.patch
___
Python
Yury Selivanov added the comment:
Attaching a patch generated with mercurial
--
Added file: http://bugs.python.org/file39148/await_01.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
Changes by Yury Selivanov yseliva...@gmail.com:
Added file: http://bugs.python.org/file39149/await_01.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: haypo
priority: normal
severity: normal
status: open
title: Implemenation of the PEP 492 - Coroutines with async and await syntax
versions: Python 3.5
___
Python tracker
Changes by STINNER Victor victor.stin...@gmail.com:
--
hgrepos: +306
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Python-bugs-list
Changes by Yury Selivanov yseliva...@gmail.com:
--
nosy: +asvetlov, yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Changes by Yury Selivanov yseliva...@gmail.com:
Removed file: http://bugs.python.org/file39147/async_01.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Changes by Yury Selivanov yseliva...@gmail.com:
Removed file: http://bugs.python.org/file39149/await_01.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
85 matches
Mail list logo
