Yury Selivanov added the comment:
I think we should close this one. Making concurrent.futures awaitable will
likely only complicate things for end-users.
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker
Alex Grönholm added the comment:
I've implemented my background-calling code in my framework via
run_in_executor() now, so this has become a non-issue for me. I have no more
interest in this patch.
--
___
Python tracker rep...@bugs.python.org
Changes by A. Jesse Jiryu Davis je...@emptysquare.net:
--
nosy: +emptysquare
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Yury Selivanov added the comment:
Alex, sure, go ahead. Although I think python-ideas would be a better choice.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
Alex Grönholm added the comment:
Where do we stand with this then? Should I start a thread on python-dev to get
the ball rolling?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
Alex Grönholm added the comment:
I've already made my case on python-ideas, so let's talk it over there.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
Guido van Rossum added the comment:
You could also withdraw. The more I think about it the more I dislike it. I
just don't think we should do *anything* that encourages confusion between
threads and tasks. They are fundamentally different concepts and should remain
so.
--
Alex Grönholm added the comment:
Why do you want to keep threads separate from asyncio? What's the downside here?
The use of helper functions is justifiable when integrating a third party
framework or similar with asyncio, but standard library components should just
integrate well with each
Guido van Rossum added the comment:
Sorry, there's no space in this issue for an answer.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
Guido van Rossum added the comment:
Every individual use case can be dealt with easily by adding simple helper
functions. I really want to keep async and threads separate. And it's no
coincidence that concurrent.futures is threadsafe; that's part of its spec.
--
Alex Grönholm added the comment:
I'm having trouble compiling the latest default (@859a45ca1e86). Getting linker
errors. I've updated the patch with Yury's tests in it. Would someone mind
running them? Apparently they do pass on 3.5b3 at least.
--
Alex Grönholm added the comment:
Yury, your tests complete even without any patches on cpython default
(@74fc1af57c72). How is that possible? I verified that they are run.
--
___
Python tracker rep...@bugs.python.org
Alex Grönholm added the comment:
Ah hehe, I forgot to actually attach the patch. Thanks Yury.
The asyncio docs need to explicitly mention that concurrent.futures.Futures can
be directly awaited from coroutines. Aside from that, I think we're set -- just
need Guido to chime in on this.
Stefan Behnel added the comment:
It would be nice to have this applied to 3.5 even. I'm aware that this is a
new feature that shouldn't go in any more at this point, but if it could
get added in 3.5.1 at least, I think it would fill a rather clear and
annoying gap when it comes to tool
Yury Selivanov added the comment:
Alex, the updated patch is attached.
Guido, do you like the new approach? Can I commit this in 3.6?
--
Added file: http://bugs.python.org/file40103/concurrent.patch
___
Python tracker rep...@bugs.python.org
Alex Grönholm added the comment:
Nevermind, I was running the wrong Python version.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Alex Grönholm added the comment:
You're right Stefan -- I too was appalled that this was not possible in 3.5 to
begin with. It feels completely natural to be able to await for concurrent
Futures. But as this is considered a feature, it'll probably have to wait until
3.6. Otherwise you'll end
Yury Selivanov added the comment:
We may be able to do this for 3.5.1 (since PEP 492 was accepted
provisionally, see
https://mail.python.org/pipermail/python-dev/2015-May/139844.html) although
it's still a pretty big new feature.
I agree. I'm -1 on pushing this to 3.5.0 or to 3.5.1.
Alex Grönholm added the comment:
Updated patch per review comments.
I also corrected the order of the lines in the new block. If _must_cancel is
True, it would have tried to call cancel() on _fut_waiter before it was set.
Now the code matches that of the original block.
The docs don't seem
Stefan Behnel added the comment:
I find it questionable to mix await and threads, as I have said several
times in the discussion about Nick Coghlan's proposal to introduce
helper functions with a similar function.
There are a couple of use cases in the context of asyncio, but definitely
also
STINNER Victor added the comment:
There are other implementations of asyncio than the one in CPython.
Pulsar and Tornado define their own Task class. The greenio project
also has a special task object. aioeventlet and aiogevent may also
benefit from a way to register new awaitable things.
I'm
Yury Selivanov added the comment:
There are other implementations of asyncio than the one in CPython.
Pulsar and Tornado define their own Task class. The greenio project
I'm not sure if it's possible (or even makes any sense) to integrate
tasks from other frameworks into asyncio.
greenio
Stefan Behnel added the comment:
Funny. I just thought about this yesterday and came up with pretty much the
same idea. +1 for the patch.
I don't think there are more classes to support here. Quite the contrary,
other tools should try to integrate via concurrent.futures.Future instead.
Yury Selivanov added the comment:
I agree with Stefan and Yury. As for the tests, Yury seemed to have those in
his patches -- I'll take a look and see if they're directly applicable.
Good idea, the tests are in a fine shape.
For Python 3.5 and earlier, there is a workaround to awaiting for
Alex Grönholm added the comment:
I agree with Stefan and Yury. As for the tests, Yury seemed to have those in
his patches -- I'll take a look and see if they're directly applicable.
For Python 3.5 and earlier, there is a workaround to awaiting for concurrent
Futures, but it requires the use
STINNER Victor added the comment:
I'm not sure that it's a good idea to start adding special cases in Task
class which is already very complex.
Instead we may add a way to register custom awaitable objects?
--
___
Python tracker
Alex Grönholm added the comment:
I think concurrent.futures.Future warrants adding support for in Task. It
predates asyncio and is generic enough. Can you elaborate on what other types
you would want to support as awaitables in Task?
--
___
Python
Alex Grönholm added the comment:
Sorry to keep you waiting. This sample code runs fine with the attached patch:
https://gist.github.com/agronholm/43c71be0028bb866753a
In short, I implemented support for concurrent.futures in the asyncio Task
class instead of making concurrent.futures aware of
Yury Selivanov added the comment:
In short, I implemented support for concurrent.futures in the asyncio Task
class instead of making concurrent.futures aware of asyncio. The __await__
implementation in concurrent.futures closely mirrors that of asyncio's Future.
I like your approach and
Alex Grönholm added the comment:
Yes, Yury's approach is wrong here -- Futures should not know about asyncio,
but asyncio should be able to handle Futures natively. This seems like the
obvious solution to me. Any counterarguments?
--
nosy: +alex.gronholm
Yury Selivanov added the comment:
Any counterarguments?
There are no counterarguments. There is no obvious way to support
concurrent.futures transparently, though:
await conc_fut
requires conc_fut to implement __await__.
So we either have to implement __await__ for concurrent futures
Stefan Behnel added the comment:
(Copying my review comment here so that it doesn't get lost as it's more of a
general design thing than a specific review comment.)
Having Future know and deal with asyncio seems wrong to me. asyncio should be
able to deal *somehow* with a Future that is being
Changes by Yury Selivanov yseliva...@gmail.com:
--
versions: -Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Changes by Yury Selivanov yseliva...@gmail.com:
Added file: http://bugs.python.org/file39622/concurrent.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
Yury Selivanov added the comment:
Yuri, is that possible?
Please see my previous comment and the attached patch :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
Changes by Yury Selivanov yseliva...@gmail.com:
--
assignee: yselivanov
components: Library (Lib), asyncio
nosy: gvanrossum, haypo, scoder, yselivanov
priority: normal
severity: normal
status: open
title: consider implementing __await__ on concurrent.futures.Future
type: enhancement
New submission from Yury Selivanov:
Maybe it's possible to give an interpretation to awaiting on a threaded
Future? __await__ could return a new asyncio Future, and add a completion
callback to the original Future that makes the asyncio Future ready and
transfers the result/exception. This
Yury Selivanov added the comment:
Added a unittest for cancellation
--
Added file: http://bugs.python.org/file39621/concurrent.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
Guido van Rossum added the comment:
So in issue24017 I wrote:
Maybe it's possible to give an interpretation to awaiting on a threaded
Future? __await__ could return a new asyncio Future, and add a completion
callback to the original Future that makes the asyncio Future ready and
transfers the
Changes by Guido van Rossum gu...@python.org:
--
Removed message: http://bugs.python.org/msg244833
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
Changes by Yury Selivanov yseliva...@gmail.com:
--
Removed message: http://bugs.python.org/msg244834
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
Yury Selivanov added the comment:
Alternative patch with monkeypatching instead of Future subclassing.
--
Added file: http://bugs.python.org/file39623/concurrent_alt.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
Guido van Rossum added the comment:
Sorry, I don't like that either. See my review.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Changes by Yury Selivanov yseliva...@gmail.com:
Added file: http://bugs.python.org/file39624/concurrent.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
Guido van Rossum added the comment:
Thinking about this more I think we should pass on this for now.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
45 matches
Mail list logo
