[issue38306] High level API for loop.run_in_executor(None, ...)?

[Guido van Rossum]

Guido van Rossum  added the comment:

Really closing.

--
nosy: +gvanrossum
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

[issue38306] High level API for loop.run_in_executor(None, ...)?

[Antoine Pietri]

Antoine Pietri  added the comment:

Yeah I'm pretty sure this solves it: 
https://github.com/python/cpython/pull/20143

Closing the issue, thanks.

--
resolution:  -> fixed

___
Python tracker 

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

[issue38306] High level API for loop.run_in_executor(None, ...)?

[Chris Jerdonek]

Chris Jerdonek  added the comment:

Is this issue the same as this one? https://bugs.python.org/issue32309

--
nosy: +chris.jerdonek

___
Python tracker 

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

[issue38306] High level API for loop.run_in_executor(None, ...)?

[Antoine Pietri]

Antoine Pietri  added the comment:

Yes, that's why I'm in favor of calling it run_thread. Because it
fundamentally *isn't* a way to run a function in an executor, it's a
way to run a function in a thread.

--

___
Python tracker 

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

[issue38306] High level API for loop.run_in_executor(None, ...)?

[Caleb Hattingh]

Caleb Hattingh  added the comment:

We can't allow both an `executor=` kwarg, as well as **kwargs for the target 
func, unfortunately. If we do `executor=`, we'll again have to force users to 
use functools.partial to wrap their functions that take kwargs.

--

___
Python tracker 

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

[issue38306] High level API for loop.run_in_executor(None, ...)?

[Antoine Pietri]

Antoine Pietri  added the comment:

On Sat, Oct 12, 2019 at 1:24 PM Caleb Hattingh  wrote:
> Even before task groups land, this API can be easily improved by adding
>
> asyncio.run_in_executor(func, *args, **kwargs)
>
> - Only valid inside a coro or async context (uses get_running_loop internally)
> - Analogous to how `loop.create_task` became `asyncio.create_task`
> - Drop having to specify `None` for the default executor
> - Users already know the `run_in_executor` name
> - Allow both positional and kwargs (we can partial internally before calling 
> loop.run_in_executor)

I think it should be run_thread() if it only works for thread.
run_in_executor() should take an executor= parameter, but it wouldn't
be as clear for beginners. I think there's value in having a simple,
explicit way of saying "I want to run this function in a thread"
without having to know what executors are.

--

___
Python tracker 

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

[issue38306] High level API for loop.run_in_executor(None, ...)?

[Caleb Hattingh]

Caleb Hattingh  added the comment:

Even before task groups land, this API can be easily improved by adding

asyncio.run_in_executor(func, *args, **kwargs)

- Only valid inside a coro or async context (uses get_running_loop internally)
- Analogous to how `loop.create_task` became `asyncio.create_task`
- Drop having to specify `None` for the default executor
- Users already know the `run_in_executor` name
- Allow both positional and kwargs (we can partial internally before calling 
loop.run_in_executor)

--
nosy: +cjrh

___
Python tracker 

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

[issue38306] High level API for loop.run_in_executor(None, ...)?

[Antoine Pietri]

Antoine Pietri  added the comment:

> run_in_executor doesn't necessarily create a new thread each time so 
> create_thread would be misleading. run_in_thread might be better.

Right, the idea was to have an analogy with create_task, because the 
run_in_executor would be wrapped in a Task. I'm okay with run_thread() too.

--

___
Python tracker 

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

[issue38306] High level API for loop.run_in_executor(None, ...)?

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I'd like to see how thread pools integrate with (not existing yet bug planned 
for 3.9) task groups before pushing forward the proposed approach.

--

___
Python tracker 

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

[issue38306] High level API for loop.run_in_executor(None, ...)?

[Paul Martin]

Paul Martin  added the comment:

run_in_executor doesn't necessarily create a new thread each time so 
create_thread would be misleading. run_in_thread might be better.

--
nosy: +primal

___
Python tracker 

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

[issue38306] High level API for loop.run_in_executor(None, ...)?

[Antoine Pietri]

Antoine Pietri  added the comment:

Actually I don't think it's possible with the current implementation to cancel 
the concurrent.Future after a timeout, so maybe we should remove that argument. 
So, this signature instead:

async def create_thread(callable, *args, *, kwargs=None, loop=None)

--

___
Python tracker 

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

[issue38306] High level API for loop.run_in_executor(None, ...)?

[Antoine Pietri]

New submission from Antoine Pietri :

In 3.7 a lot of high level functions have been added to the asyncio API, but 
nothing to start blocking functions as non-blocking threads. You still have to 
call get_event_loop() then await loop.run_in_executor(None, callable). I think 
this pattern is *very* common and could use a higher level interface.

Would an API like this make sense?

async def create_thread(callable, *args, *, kwargs=None, loop=None, 
timeout=None)

Then it could just be used like this:

await asyncio.create_thread(my_blocking_read, 4096, timeout=10)

This API could wrap the run_in_executor in an asyncio.Task, that way
you wouldn't have to await it to start the thread. There's evidence
that this has confused people in the past:

https://stackoverflow.com/questions/54263558/is-asyncio-run-in-executor-specified-ambiguously

--
components: asyncio
messages: 353456
nosy: antoine.pietri, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: High level API for loop.run_in_executor(None, ...)?
type: enhancement
versions: Python 3.9

___
Python tracker 

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