On 8/11/2016 11:55 PM, Lawrence D’Oliveiro wrote:
On Friday, August 12, 2016 at 2:25:05 AM UTC+12, Terry Reedy wrote:
When I read something like "Python finally acquired an event loop in
3.4" I wonder where people have been. The tk event loop has been in
Python perhaps for 2 decades...
As
On 08/11/2016 10:47 PM, Paul Rudin wrote:
Steven D'Aprano writes:
[...]
In this case, all the work is pure computation, so I don't expect to save
any time by doing this, because the work is still all being done in the
same process/thread, not in parallel. It may even take a little bit
On Saturday, August 13, 2016 at 8:26:05 PM UTC+12, Marko Rauhamaa wrote:
> ... (unless Python takes Linux's AIO API into use, which
> would be groundbreaking).
Last I looked, asynchronous I/O on Linux was still a work in progress. The
whole POSIX API has been grounded in the assumption that all
On 08/11/2016 07:14 AM, Steven D'Aprano wrote:
On Thu, 11 Aug 2016 03:06 pm, Paul Rubin wrote:
The basic characteristic of asynchronous programming is that it involves
changing all your usual blocking i/o calls to non-blocking ones, so your
program can keep running as soon as your request
Marko Rauhamaa writes:
> Also, one must be careful with file access, which is necessarily
> blocking on linux (unless Python takes Linux's AIO API into use, which
> would be groundbreaking).
AIO is a possibility for i/o on an already-open file and I think there
may be other
tabase API has yet been ported to asyncio,
has it? That means database access is not yet quite usable with asyncio
(or any other form of asynchronous programming).
Also, one must be careful with file access, which is necessarily
blocking on linux (unless Python takes Linux's AIO API into use,
Steven D'Aprano writes:
>> await asyncio.sleep(0.2) # pretend to do some real work
> That is *awesome*. Thank you for the example!
Keep in mind that the above basically takes the task off the list of
runnables for 0.2 seconds, so it sits doing nothing and
On Fri, 12 Aug 2016 03:47 pm, Paul Rudin wrote:
> Steven D'Aprano writes:
>
>> Thanks to everyone who has answered, I think I'm slowly starting to get
>> it now. Let's see if we can come up with a toy example that doesn't
>> involve low-level socket programming :-)
Steven D'Aprano writes:
> Thanks to everyone who has answered, I think I'm slowly starting to get it
> now. Let's see if we can come up with a toy example that doesn't involve
> low-level socket programming :-)
>
> Let me simulate a slow function call:
>
>
> import
Steven D'Aprano writes:
> How do I write work() so that it cooperatively multi-tasks with other ...
> threads? processes? what the hell do we call these things? What does this
> example become in the asynchronous world?
If it's heavily computational then you have to
On Friday, August 12, 2016 at 2:25:05 AM UTC+12, Terry Reedy wrote:
> When I read something like "Python finally acquired an event loop in
> 3.4" I wonder where people have been. The tk event loop has been in
> Python perhaps for 2 decades...
As was pointed out to me just a few days ago,
On Fri, Aug 12, 2016 at 10:08 AM, Steven D'Aprano
wrote:
> Let me simulate a slow function call:
>
>
> import random, time
>
> def work(id):
> print("starting with id", id)
> workload = random.randint(5, 15)
> for i in range(workload):
>
Thanks to everyone who has answered, I think I'm slowly starting to get it
now. Let's see if we can come up with a toy example that doesn't involve
low-level socket programming :-)
Let me simulate a slow function call:
import random, time
def work(id):
print("starting with id", id)
Steven D'Aprano writes:
> But what's the point in doing it asynchronously if I have to just wait for
> it to complete?
> begin downloading in an async thread
> twiddle thumbs, doing nothing
> process download
Suppose the remote server is overloaded so it sends
On Fri, Aug 12, 2016 at 12:55 AM, Steven D'Aprano
wrote:
> On Thu, 11 Aug 2016 02:41 pm, Chris Angelico wrote:
>
>> Consider these three ways of doing a database transaction:
>>
>> def synchronous(id):
>> trn = conn.begin_transaction()
>> trn.execute("select
On Thu, 11 Aug 2016 03:34 pm, Paul Rudin wrote:
> Steven D'Aprano <steve+pyt...@pearwood.info> writes:
>
>>
>> Is there a good beginner's tutorial introducing the basics of
>> asynchronous programming? Starting with, why and where would you use it?
>
>
Steven D'Aprano writes:
>
> But what's the point in doing it asynchronously if I have to just wait for
> it to complete?
>
> begin downloading in an async thread
> twiddle thumbs, doing nothing
> process download
If you have nothing else to do, then there's no
Michael Selik writes:
> On Thu, Aug 11, 2016 at 11:46 AM Michael Selik
> wrote:
>
>> On Thu, Aug 11, 2016 at 11:01 AM Steven D'Aprano <
>> steve+pyt...@pearwood.info> wrote:
>>
>>> That ... looks wrong. You're taking something which looks like a
On Thu, Aug 11, 2016 at 11:46 AM Michael Selik
wrote:
> On Thu, Aug 11, 2016 at 11:01 AM Steven D'Aprano <
> steve+pyt...@pearwood.info> wrote:
>
>> That ... looks wrong. You're taking something which looks like a procedure
>> in the first case (trn.execute), so it
On Thu, Aug 11, 2016 at 11:01 AM Steven D'Aprano
wrote:
> That ... looks wrong. You're taking something which looks like a procedure
> in the first case (trn.execute), so it probably returns None, and yielding
> over it. Even it that's not wrong, and it actually
On Thu, 11 Aug 2016 02:41 pm, Chris Angelico wrote:
> Consider these three ways of doing a database transaction:
>
> def synchronous(id):
> trn = conn.begin_transaction()
> trn.execute("select name from people where id=%d", (id,))
> name, = trn.fetchone()
> trn.execute("update
Steven D'Aprano :
> Say I want to download data from a network, and it will take a long
> time. If I can do the read in parallel to something else, that makes
> sense:
>
> begin downloading in another thread/process
> make a coffee
> process download
>
> But
On Thu, 11 Aug 2016 03:06 pm, Paul Rubin wrote:
> The basic characteristic of asynchronous programming is that it involves
> changing all your usual blocking i/o calls to non-blocking ones, so your
> program can keep running as soon as your request is started.
That's the bit that confu
Steven D'Aprano :
> Instructions unclear, poked myself in the eye with a sharp stick.
I have updated my Dining Philosophers example for Python 3.5:
http://pacujo.net/~marko/philosophers.py>
It demonstrates how to get an event loop and start a number of asyncs
On 8/11/2016 2:34 AM, Christian Gollwitzer wrote:
Am 11.08.16 um 06:38 schrieb Terry Reedy:
You might be able to glean something from the succession of files I
uploaded to
https://bugs.python.org/issue27546
Integrate tkinter and asyncio (and async)
I started with just mixing tk and asyncio
On Thu, 11 Aug 2016 07:33 pm, Chris Angelico wrote:
> Yes,
> threading bugs can be harder to debug; but only when you've violated
> the other principles.
Especially the principle "Avoid threaded programming".
Some people, when faced with a problem, Now they think "I know, I'll have
use two
On Thu, 11 Aug 2016 03:34 pm, Paul Rudin wrote:
> Steven D'Aprano <steve+pyt...@pearwood.info> writes:
>
>>
>> Is there a good beginner's tutorial introducing the basics of
>> asynchronous programming? Starting with, why and where would you use it?
>
>
Chris Angelico :
> On Thu, Aug 11, 2016 at 5:55 PM, Marko Rauhamaa wrote:
>> My favorite asynchronous development model is the "callback hell," where
>> each cell of the state/event matrix is represented by a method (or at
>> least a switch case in C) and each
Chris Angelico writes:
> On Thu, Aug 11, 2016 at 7:45 PM, Steven D'Aprano
> wrote:
>> I don't know whether you would call that a callback. I suppose it could be,
>> in
>> the sense that you might say:
>>
>>
On Thu, Aug 11, 2016 at 7:45 PM, Steven D'Aprano
wrote:
> I don't know whether you would call that a callback. I suppose it could be, in
> the sense that you might say:
>
> button.set_mouseup_function(mouseUp)
>
> but I'm used to thinking of it as a
On Thursday 11 August 2016 16:21, Christian Gollwitzer wrote:
> In typical GUI code, there are usually not that many places qhere ou
> have sequential code. A simple exmaple might be a counter. Using asyncio
> and a properly integrated GUI toolkit, you could write it as (pseudo-code)
>
> async
s that. (That's one of the advantages of Python's
generator-based async model - although it's not perfect.)
> Instead, I strongly prefer asynchronous programming and multiprocessing.
Multiprocessing is *exactly* as complicated as multithreading, with
the additional overhead of having to pass stat
g.
* No cancellation.
* Deadlocks and/or race conditions are virtually guaranteed.
* Error symptoms are highly nonlocal making debugging very tricky.
Instead, I strongly prefer asynchronous programming and multiprocessing.
However, I'm afraid Python is following an unfortunate trend with
asy
Christian Gollwitzer writes:
> I'm convinced that it is possible to integrate Tcl's event loop with
> asyncio's loop without regular update polling. This might require a
> patch to Tkinter at the C level. For example, an easy way is to put
> Tcl/Tk in it's own thread. ...
I did
Am 11.08.16 um 06:38 schrieb Terry Reedy:
You might be able to glean something from the succession of files I
uploaded to
https://bugs.python.org/issue27546
Integrate tkinter and asyncio (and async)
I started with just mixing tk and asyncio callbacks. After some
struggle with similar question
. Asynchronous programming is event based
programming. In fact if you drop down to the C level, it works the same
- you get callbacks when new data arives over a socket, or when a timer
triggers. asyncio is just a way that makes writing stateful callback
handlers easier, in the same way
Steven D'Aprano <steve+pyt...@pearwood.info> writes:
>
> Is there a good beginner's tutorial introducing the basics of asynchronous
> programming? Starting with, why and where would you use it?
You could do worse than watch Dave Beazley's pycon talk:
https://www.youtube.com/watc
On Thu, Aug 11, 2016 at 3:06 PM, Paul Rubin wrote:
> The basic reason to do it is it lets you serve a lot of concurrent i/o
> channels (network connections, say) without using threads. If you want
> to read a packet, you launch a non-blocking read that returns
>
Steven D'Aprano <steve+pyt...@pearwood.info> writes:
> Is there a good beginner's tutorial introducing the basics of asynchronous
> programming? Starting with, why and where would you use it?
You might look at some node.js tutorials since there are about a
gazillion of them and some
On Thu, Aug 11, 2016 at 1:53 PM, Steven D'Aprano
wrote:
> How is this the same as, or different from, event-based programming? I'm
> familiar with programming in an event-based language where the interpreter
> itself provides an event loop and dispatches messages to
On 8/10/2016 11:53 PM, Steven D'Aprano wrote:
The latest versions of Python are introducing new keywords for
asynchronous programming, async and await. See PEP 492:
https://www.python.org/dev/peps/pep-0492/
Is there a good beginner's tutorial introducing the basics of
asynchronous programming
The latest versions of Python are introducing new keywords for asynchronous
programming, async and await. See PEP 492:
https://www.python.org/dev/peps/pep-0492/
Is there a good beginner's tutorial introducing the basics of asynchronous
programming? Starting with, why and where would you use
I posted this message earlier to the list, but realized that URLs appear
broken with '.' at the end of URL. Sorry for that mistake and this duplicate!
asyncoro is a framework for developing concurrent programs with
asynchronous event completions and coroutines. Asynchronous
completions currently
in asynchronous
programming (server-side javascript with NodeJS, Python’s Tornado,
Ruby’s Event Machine, etc.) as well as Websockets, NoSQL databases,
queues, XMPP and others.
We’d be thrilled to have you amongst us and hear your story on this
matter! We thought this could be the opportunity
44 matches
Mail list logo