[issue27598] Add SizedIterable to collections.abc and typing
Sven R. Kunze added the comment: I am way too late to the discussion but I also support the term "collections". I think it also helps developers coming from a C# background: https://msdn.microsoft.com/library/92t2ye13(v=vs.110).aspx -- nosy: +srkunze ___ Python tracker <http://bugs.python.org/issue27598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24578] [RFE] Add asyncio.wait_for_result API
New submission from Sven R. Kunze: In order to complement http://bugs.python.org/issue24571, this is another high-level convenience API for asyncio to treat an awaitable like a usual subroutine (credits go to Nick Coghlan): # Call awaitable from synchronous code def wait_for_result(awaitable): """Usage: result = asyncio.wait_for_result(awaitable)""" return asyncio.get_event_loop().run_until_complete(awaitable.__await__()) It may not be that conceptually dense, however, I feel for projects transitioning from the classical subroutine world to the asyncio world, this functionality might prove useful to bridge both worlds seamlessly when necessary. -- components: asyncio messages: 246373 nosy: gvanrossum, haypo, srkunze, yselivanov priority: normal severity: normal status: open title: [RFE] Add asyncio.wait_for_result API versions: Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue24578> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24578] [RFE] Add asyncio.wait_for_result API
Changes by Sven R. Kunze : -- nosy: +giampaolo.rodola, ncoghlan, pitrou -srkunze type: -> enhancement ___ Python tracker <http://bugs.python.org/issue24578> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24578] [RFE] Add asyncio.wait_for_result API
Changes by Sven R. Kunze : -- nosy: +srkunze ___ Python tracker <http://bugs.python.org/issue24578> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24571] [RFE] Add asyncio.blocking_call API
Sven R. Kunze added the comment: Thanks for taking the initiative here, Nick. I created a follow-up on this: http://bugs.python.org/issue24578 In order to bridge both worlds, projects might need convenient way from and to either world (classic and asyncio). -- components: +asyncio nosy: +srkunze ___ Python tracker <http://bugs.python.org/issue24571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24571] [RFE] Add asyncio.blocking_call API
Sven R. Kunze added the comment: 2 remarks: 1) I would rather go for a more comprehensible name such as 'get_awaitable' instead of 'blocking_call'. Later reminds me of the execution of f which is not the case. 2) redundant ) in the end of """Usage: result = await asyncio.blocking_call(f, *args, **kwds))""" -- ___ Python tracker <http://bugs.python.org/issue24571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24571] [RFE] Add asyncio.call_async API
Sven R. Kunze added the comment: > Why bother with asyncio at all? Good question. My initial reaction to async+await was: 'great, finally a Pythonic (i.e. a single, explicit) way to do squeeze out more of our servers'. Moreover, the goal of 'being more like classic code' + 'having reasonable tracebacks' reads like 'nice, ready for production code'. After reading the documentation, I was slightly confused by: coroutines, tasks, futures which somehow feel very similar. But because of the introduction of 'await', I thought, we would not need to bother with that at all. Then, people started to tell me that asyncio and normal execution could never interact with each other. I cannot believe that. Python always gave me convenient tools. I cannot believe it should be different this time. I can use properties the same way as attributes, i.e. I can substitute them with each other seamlessly. I can call class methods the same way as instance methods, i.e. I can substitute them with each other seamlessly. I can call functions that raise exceptions the same way as functions that raise no exceptions, i.e. I can substitute them with each other seamlessly. It is just perfect. Comparing the projects I am involved, those using Python proceed at a much greater pace just because of these convenient tools. So, I wanted to leverage asyncio's power without touching million lines of code as well. If asyncio is not the right tool, that is fine with me, but then I do not get why threading does not have its own syntax (and goals described above) whereas asyncio does. To me, I could accomplish the same more or less with both tools. -- ___ Python tracker <http://bugs.python.org/issue24571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24571] [RFE] Add asyncio.call_async API
Sven R. Kunze added the comment: > I also fear adding too many functions to do the same things. > > For example, scheduling the execution of a coroutine can now be done by: > * asyncio.async(coro) > * asyncio.Task(coro) > * loop.create_task(coro) > * asyncio.ensure_task(coro) If you ask me, that does not look very Pythonic to me. -- ___ Python tracker <http://bugs.python.org/issue24571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24571] [RFE] Add asyncio.call_async API
Sven R. Kunze added the comment: @David What is the purpose of multitasking code? -- ___ Python tracker <http://bugs.python.org/issue24571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24571] [RFE] Add asyncio.background_call API
Sven R. Kunze added the comment: > ... this sounds like it is encouraging staying ignorant. True. However, I being ignorant about the complexity eventually led to the development of high-level languages like Python. Each time, a next generation simply asks the question: 'does it really need to be that complicated?' And each time, there is a solution. We will get there. I have to admit, I do not stay ignorant because of convenience APIs but because I feel things made overly complicated. I am not sure if we talk about asyncio anymore. I would say everything in Python regarding concurrency/parallelism needs to be put into perspective: Modules I know MIGHT be interesting for me: - concurrent - threading - asyncio - multiprocessing But I have no idea why/when to use which one. AND more importantly, statements like "This class is almost compatible with concurrent.futures.Future." (https://docs.python.org/3/library/asyncio-task.html#asyncio.Future) do not help. If it they are that compatible, why do we need both and when do I need which one? Or is this just another internal detail of implementation I can really be ignorant of? >From what I can tell right now (I read deeper into the topic, but always >correct me if I am wrong), my perspective of the modules are now: API of your application ^ ^ 1) either asynchronous/event loop/asyncio 2) or synchronous/single event = start of program ^ ^ the logic of the application ^ ^ usage of other components ^ ^ 1) either 1 thread/imperative/line by line 2) or multithread/concurrent/parallel 3) or multiprocess/concurrent/parallel My understanding is that asyncio is a way to implement the API of your application whereas concurrent/threading/multiprocessing provide means for more efficient execution of the underlying logic. However, that cannot be entirely true, as I have already seen modules using asyncio to communication asynchronously with databases (to be honest that is what its name suggests async IO). So, what? Seems like we can use asyncio also for communication with other components as well which my intuition held true as well. That is why I have trouble to understand why it is considered wrong to do the same with 'normal' functions (to me they are just other components). AND it can also be the other way round: using concurrent/threading/multiprocessing for implementing the API of your application. -- ___ Python tracker <http://bugs.python.org/issue24571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
