[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Alex Grönholm]

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
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[A. Jesse Jiryu Davis]

Changes by A. Jesse Jiryu Davis je...@emptysquare.net:


--
nosy: +emptysquare

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Alex Grönholm]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Alex Grönholm]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Guido van Rossum]

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Alex Grönholm]

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 other. Requiring boilerplate wrappers for such use 
seems unreasonable to me.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Guido van Rossum]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Guido van Rossum]

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Alex Grönholm]

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Alex Grönholm]

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
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Alex Grönholm]

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Stefan Behnel]

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 integration.

If someone explained async/await as a new syntax feature for async
programming to me, and then mentioned that you can't await a Future, I'd be
rather surprised, to put it mildly.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

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
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Alex Grönholm]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Alex Grönholm]

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 up your app requiring a specific micro-release which 
is a big no-no in the Python world, as far as features go at least.

But if this is considered a bugfix, it could still go into 3.5.0... *wink 
wink*. That's what I'm hoping for of course.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Alex Grönholm]

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 to explicitly say anywhere that they only accept asyncio's 
Futures and not concurrent Futures, so I'm unsure if any changes are needed 
there at all.

--
Added file: http://bugs.python.org/file40106/concurrent.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Stefan Behnel]

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 a major one: blocking database drivers. Normally, applications keep a
pool of connections open to a database and use a bounded size for it in
order to limit the resource usage on server side. Starting a thread pool of
the same size in the application provides a trivial way to make use of
these connections concurrently and efficiently with a blocking database
driver and/or ORM (e.g. SQLAlchemy). concurrent.futures makes this really
easy.

 The argument but they're both Futures seems pretty bogus to me.

concurrent.futures.Future is not just any Future, it's the one that is in
the standard library, i.e. pretty much the only one that every tool could
agree on (whether or not it knows about or uses asyncio). The fact that
it's thread-safe doesn't really matter to me.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[STINNER Victor]

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 not opposed to support concurrent.futures.Future object. I don't
like the idea of starting to add a special case for one module. Others
may want to do the same for their library.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

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 simply inherits its task class from asyncio.Task, and will
automatically support concurrent.futures if we support them in
asyncio.

 I'm not opposed to support concurrent.futures.Future object. I don't
 like the idea of starting to add a special case for one module. Others
 may want to do the same for their library.

concurrent.futures is in a unique position -- it's already supported and
integrated in asyncio.  We have executors and they are even used for
DNS lookups.  Supporting concurrent.futures in asyncio.Task seems 
natural to me.

I like Alex's approach -- his idea of '__await__' for concurrent.Future
is very generic, so any other framework can integrate it.  Creating
any kind of registry in asyncio.Task seems a bit unnecessary to me at 
this stage.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Stefan Behnel]

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

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 concurrent 
 Futures, but it requires the use of the undocumented wrap_future() function. 
 It is the fact that it's undocumented that bothers me.

I didn't even know about it :(  Please create an issue.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Alex Grönholm]

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 of the undocumented wrap_future() function. It 
is the fact that it's undocumented that bothers me.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[STINNER Victor]

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 rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Alex Grönholm]

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 tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Alex Grönholm]

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 asyncio. The __await__ 
implementation in concurrent.futures closely mirrors that of asyncio's Future.

--
Added file: http://bugs.python.org/file40090/asyncio_await.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

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 the proposed patch. I think we should commit this in 
3.6 (the final patch should include docs  tests).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Alex Grönholm]

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

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

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 and provide 
some kind of registry for frameworks, or we can implement a wrapper function:

await asyncio_compat(conc_fut)

Anyways, concrete ideas and API suggestions are welcome.

--
nosy: +Yury.Selivanov

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Stefan Behnel]

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 awaited, but a Future 
shouldn't require asyncio in order to be awaited.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

Changes by Yury Selivanov yseliva...@gmail.com:


--
versions:  -Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

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
versions: Python 3.5, Python 3.6

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

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 would have to use
 loop.call_soon_threadsafe() to transfer control from the exector thread to
 the thread where the loop is running.

It didn't occur to me that we can implement __await__ on concurrent.Future to 
integrate it *with* asyncio.  I guess it makes sense (although we don't have 
this kind of integration in 3.4 with 'yield from')

 The only thing I don't know is whether it's possible for __await__ to
 return a Future.

It is -- we just have to return iter(asyncio.Future())

Please see the attached patch -- it needs some more tuning, but it demonstrates 
that the integration is possible.

--
keywords: +patch
Added file: http://bugs.python.org/file39620/concurrent.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Guido van Rossum]

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 result/exception. This would have to use
loop.call_soon_threadsafe() to transfer control from the exector thread to
the thread where the loop is running.

The only thing I don't know is whether it's possible for __await__ to
return a Future.


Yuri, is that possible?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Guido van Rossum]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Guido van Rossum]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Yury Selivanov]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24383] consider implementing __await__ on concurrent.futures.Future

[Guido van Rossum]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com