"Frank Millman" wrote in message news:n8et0d$hem$1...@ger.gmane.org...
I have read the other messages, and I can see that there are some clever
ideas there. However, having found something that seems to work and that I
feel comfortable with, I plan to run with this for the time being.
A quic
Le 28 janv. 2016 22:52, "Ian Kelly" a écrit :
>
> On Thu, Jan 28, 2016 at 2:23 PM, Maxime S wrote:
> >
> > 2016-01-28 17:53 GMT+01:00 Ian Kelly :
> >>
> >> On Thu, Jan 28, 2016 at 9:40 AM, Frank Millman
wrote:
> >>
> >> > The caller requests some data from the database like this.
> >> >
> >> >
"Ian Kelly" wrote in message
news:calwzidn6nft_o0cfhw1itwja81+mw3schuecadvcen3ix6z...@mail.gmail.com...
As I commented in my previous message, asyncio.Queue is not
thread-safe, so it's very important that the put calls here be done on
the event loop thread using event_loop.call_soon_threadsafe.
On Jan 28, 2016 3:07 PM, "Maxime Steisel" wrote:
>
> But it is a pretty strange idea to call two fetch*() method concurrently
anyways.
If you want to process rows concurrently and aren't concerned with
processing them in order, it may be attractive to create multiple threads /
coroutines, pass th
On Thu, Jan 28, 2016 at 2:23 PM, Maxime S wrote:
>
> 2016-01-28 17:53 GMT+01:00 Ian Kelly :
>>
>> On Thu, Jan 28, 2016 at 9:40 AM, Frank Millman wrote:
>>
>> > The caller requests some data from the database like this.
>> >
>> >return_queue = asyncio.Queue()
>> >sql = 'SELECT ...'
>> >
2016-01-28 17:53 GMT+01:00 Ian Kelly :
> On Thu, Jan 28, 2016 at 9:40 AM, Frank Millman wrote:
>
> > The caller requests some data from the database like this.
> >
> >return_queue = asyncio.Queue()
> >sql = 'SELECT ...'
> >request_queue.put((return_queue, sql))
>
> Note that since thi
"Ian Kelly" wrote in message
news:CALwzidnGbz7kM=d7mkua2ta9-csfn9u0ohl0w-x5bbixpcw...@mail.gmail.com...
On Jan 28, 2016 4:13 AM, "Frank Millman" wrote:
>
> I *think* I have this one covered. When the caller makes a request, it
creates an instance of an asyncio.Queue, and includes it with the
On Jan 28, 2016 4:13 AM, "Frank Millman" wrote:
>
> "Chris Angelico" wrote in message
news:captjjmr162+k4lzefpxrur6wxrhxbr-_wkrclldyr7kst+k...@mail.gmail.com...
>>
>>
>> On Thu, Jan 28, 2016 at 8:13 PM, Frank Millman
wrote:
>> > Run the database handler in a separate thread. Use a queue.Queue to
On Thu, Jan 28, 2016 at 9:40 AM, Frank Millman wrote:
> I have hit a snag. It feels like a bug in 'await q.get()', though I am sure
> it is just me misunderstanding how it works.
>
> I can post some working code if necessary, but here is a short description.
>
> Here is the database handler - 'req
"Chris Angelico" wrote in message
news:captjjmr162+k4lzefpxrur6wxrhxbr-_wkrclldyr7kst+k...@mail.gmail.com...
On Thu, Jan 28, 2016 at 8:13 PM, Frank Millman wrote:
> Run the database handler in a separate thread. Use a queue.Queue to send
> requests to the handler. Use an asyncio.Queue to send
On Thu, Jan 28, 2016 at 8:13 PM, Frank Millman wrote:
> Run the database handler in a separate thread. Use a queue.Queue to send
> requests to the handler. Use an asyncio.Queue to send results back to the
> caller, which can call 'await q.get()'.
>
> I ran a quick test and it seems to work. What d
On Thu, Jan 28, 2016 at 10:11 PM, Frank Millman wrote:
>>
>> The other risk is that the wrong result will be queried (two async
>> tasks put something onto the queue - which one gets the first
>> result?), which could either be coped with by simple sequencing (maybe
>> this happens automatically,
"Ian Kelly" wrote in message
news:CALwzidkr-fT6S6wH2caNaxyQvUdAw=x7xdqkqofnrrwzwnj...@mail.gmail.com...
On Wed, Jan 27, 2016 at 10:14 AM, Ian Kelly wrote:
> Unfortunately this doesn't actually work at present.
> EventLoop.run_in_executor swallows the StopIteration exception and
> just returns
"Ian Kelly" wrote in message
news:CALwzidk-RBkB-vi6CgcEeoFHQrsoTFvqX9MqzDD=rny5boc...@mail.gmail.com...
On Tue, Jan 26, 2016 at 7:15 AM, Frank Millman wrote:
>
> If I return the cursor, I can iterate over it, but isn't this a blocking
> operation? As far as I know, the DB adaptor will only ac
"Ian Kelly" wrote in message
news:calwzidn6tvn9w-2qnn2jyvju8nhzn499nptfjn9ohjddceb...@mail.gmail.com...
On Wed, Jan 27, 2016 at 7:40 AM, Frank Millman wrote:
>
> Assume a slow function -
>
> async def slow_function(arg1, arg2):
>[do stuff]
>
> It now looks like this -
>
> async def slow_f
On Wed, Jan 27, 2016 at 10:14 AM, Ian Kelly wrote:
> Unfortunately this doesn't actually work at present.
> EventLoop.run_in_executor swallows the StopIteration exception and
> just returns None, which I assume is a bug.
http://bugs.python.org/issue26221
--
https://mail.python.org/mailman/listin
On Wed, Jan 27, 2016 at 9:15 AM, Ian Kelly wrote:
> class CursorWrapper:
>
> def __init__(self, cursor):
> self._cursor = cursor
>
> async def __aiter__(self):
> return self
>
> async def __anext__(self):
> loop = asyncio.get_event_loop()
> return await
On Wed, Jan 27, 2016 at 7:40 AM, Frank Millman wrote:
> "Ian Kelly" wrote in message
> news:CALwzidk-RBkB-vi6CgcEeoFHQrsoTFvqX9MqzDD=rny5boc...@mail.gmail.com...
>
>> You probably want an asynchronous iterator here. If the cursor doesn't
>> provide that, then you can wrap it in one. In fact, this
"Ian Kelly" wrote in message
news:CALwzidk-RBkB-vi6CgcEeoFHQrsoTFvqX9MqzDD=rny5boc...@mail.gmail.com...
On Tue, Jan 26, 2016 at 7:15 AM, Frank Millman wrote:
>
> If I return the cursor, I can iterate over it, but isn't this a blocking
> operation? As far as I know, the DB adaptor will only ac
> "Alberto" == Alberto Berti writes:
Alberto> async external_coro(): # this is the calling context, which is
a coro
Alberto> async with transction.begin():
Alberto> o = MyObject
Alberto> # maybe other stuff
ops... here it is "o = MyObject
> "Frank" == Frank Millman writes:
Frank> Now I have another problem. I have some classes which retrieve some
Frank> data from the database during their __init__() method. I find that it
Frank> is not allowed to call a coroutine from __init__(), and it is not
Frank> allowed to
On Tue, Jan 26, 2016 at 7:15 AM, Frank Millman wrote:
> I am making some progress, but I have found a snag - possibly unavoidable,
> but worth a mention.
>
> Usually when I retrieve rows from a database I iterate over the cursor -
>
>def get_rows(sql, params):
>cur.execute(sql, params)
"Frank Millman" wrote in message news:n8038j$575$1...@ger.gmane.org...
I am developing a typical accounting/business application which involves a
front-end allowing clients to access the system, a back-end connecting to
a database, and a middle layer that glues it all together.
[...]
The
Marko Rauhamaa writes:
> Note that neither the multithreading model (which I dislike) nor the
> callback hell (which I like) suffer from this problem.
There are some runtimes (GHC and Erlang) where everything is nonblocking
under the covers, which lets even the asyncs be swept under the rug.
Simi
Rustom Mody :
> Bah -- What a bloody mess!
> And thanks for pointing this out, Ian.
> Keep wondering whether my brain is atrophying, or its rocket science or...
I'm afraid the asyncio idea will not fly.
Adding the keywords "async" and "await" did make things much better, but
the programming mode
On Monday, January 25, 2016 at 9:16:13 PM UTC+5:30, Ian wrote:
> On Mon, Jan 25, 2016 at 8:32 AM, Ian Kelly wrote:
> >
> > On Jan 25, 2016 2:04 AM, "Frank Millman" wrote:
> >>
> >> "Ian Kelly" wrote in message
> >>>
> >>> This seems to be a common misapprehension about asyncio programming.
> >>>
On Mon, Jan 25, 2016 at 8:32 AM, Ian Kelly wrote:
>
> On Jan 25, 2016 2:04 AM, "Frank Millman" wrote:
>>
>> "Ian Kelly" wrote in message
>> news:calwzidngogpx+cpmvba8vpefuq4-bwmvs0gz3shb0owzi0b...@mail.gmail.com...
>>>
>>> This seems to be a common misapprehension about asyncio programming.
>>>
On Jan 25, 2016 2:04 AM, "Frank Millman" wrote:
>
> "Ian Kelly" wrote in message
news:calwzidngogpx+cpmvba8vpefuq4-bwmvs0gz3shb0owzi0b...@mail.gmail.com...
>>
>> This seems to be a common misapprehension about asyncio programming.
>> While coroutines are the focus of the library, they're based on
"Ian Kelly" wrote in message
news:calwzidngogpx+cpmvba8vpefuq4-bwmvs0gz3shb0owzi0b...@mail.gmail.com...
On Sat, Jan 23, 2016 at 7:38 AM, Frank Millman wrote:
> Here is the difficulty. The recommended way to handle a blocking
> operation
> is to run it as task in a different thread, using run_i
"Ian Kelly" wrote in message
news:calwzidngogpx+cpmvba8vpefuq4-bwmvs0gz3shb0owzi0b...@mail.gmail.com...
On Sat, Jan 23, 2016 at 7:38 AM, Frank Millman wrote:
> Here is the difficulty. The recommended way to handle a blocking
> operation
> is to run it as task in a different thread, using run_
"Frank Millman" wrote in message news:n8038j$575$1...@ger.gmane.org...
So I thought I would ask here if anyone has been through a similar
exercise, and if what I am going through sounds normal, or if I am doing
something fundamentally wrong.
Thanks for any input
Just a quick note of thank
On Sat, Jan 23, 2016 at 8:44 AM, Ian Kelly wrote:
> This is where it would make sense to me to use callbacks instead of
> subroutines. You can structure your __init__ method like this:
Doh.
s/subroutines/coroutines
--
https://mail.python.org/mailman/listinfo/python-list
On Sat, Jan 23, 2016 at 7:38 AM, Frank Millman wrote:
> Here is the difficulty. The recommended way to handle a blocking operation
> is to run it as task in a different thread, using run_in_executor(). This
> method is a coroutine. An implication of this is that any method that calls
> it must als
On Sun, Jan 24, 2016 at 1:38 AM, Frank Millman wrote:
> I find I am bumping my head more that I expected, so I thought I would try
> to get some feedback here to see if I have some flaw in my approach, or if
> it is just in the nature of writing an asynchronous-style application.
I don't have a l
Hi all
I am developing a typical accounting/business application which involves a
front-end allowing clients to access the system, a back-end connecting to a
database, and a middle layer that glues it all together.
Some time ago I converted the front-end from a multi-threaded approach to an
Ian Kelly :
> Callbacks can easily schedule coroutines, but they can't wait on them,
> because that would require suspending their execution, dropping back
> to the event loop, and resuming later -- in other words, the callback
> would need to be a coroutine also.
I guess the key is, can a callba
On Jul 24, 2014 1:26 AM, "Marko Rauhamaa" wrote:
>
> Terry Reedy :
>
> > 18.5.3. Tasks and coroutines, seems to be devoid of event wait
> > examples. However, there is a 'yield from' network example in 18.5.5
> > Streams using socket functions wrapped with coroutines. These should
> > definitely b
Terry Reedy :
> 18.5.3. Tasks and coroutines, seems to be devoid of event wait
> examples. However, there is a 'yield from' network example in 18.5.5
> Streams using socket functions wrapped with coroutines. These should
> definitely be used instead of sleep. In fact, for cross-platform
> network
On 7/24/2014 1:15 AM, Saimadhav Heblikar wrote:
On 24 July 2014 05:54, Terry Reedy wrote:
On 7/23/2014 6:43 AM, Saimadhav Heblikar wrote:
Hi,
The example in question is
https://docs.python.org/3/library/asyncio-task.html#example-hello-world-coroutine.
I'd like to learn the purpose of the st
Saimadhav Heblikar :
> For situations where I dont really know how long a function is going
> to take(say waiting for user input or a network operation), I am
> better off using callbacks than "yield from asyncio.sleep()". Is my
> understanding correct?
If you choose the coroutine style of progra
On 24 July 2014 05:54, Terry Reedy wrote:
> On 7/23/2014 6:43 AM, Saimadhav Heblikar wrote:
>>
>> Hi,
>>
>> The example in question is
>>
>> https://docs.python.org/3/library/asyncio-task.html#example-hello-world-coroutine.
>> I'd like to learn the purpose of the statement
>> "yield from asyncio.s
On 7/23/2014 6:43 AM, Saimadhav Heblikar wrote:
Hi,
The example in question is
https://docs.python.org/3/library/asyncio-task.html#example-hello-world-coroutine.
I'd like to learn the purpose of the statement
"yield from asyncio.sleep(2)" in that example.
In particular, I'd like to know if asyn
asyncio.sleep() returns you a Future. When you yield from a future,
your coroutine blocks, until the Future completes. In the meantime,
event loop continutes to execute other things that are waiting to be
executed. The Future returned from asyncio.sleep gets completed after
specified seconds.
2014
Hi,
The example in question is
https://docs.python.org/3/library/asyncio-task.html#example-hello-world-coroutine.
I'd like to learn the purpose of the statement
"yield from asyncio.sleep(2)" in that example.
In particular, I'd like to know if asyncio.sleep() is used as a
substitute for slow/time
"Ian Kelly" wrote in message
news:CALwzidmzG_WA5shw+PS4Y976M4DVTOwE=zb+kurvcpj3n+5...@mail.gmail.com...
> On Fri, Jun 13, 2014 at 5:42 AM, Frank Millman wrote:
>> Now I want to use the functionality of asyncio by using a 'yield from' to
>> suspend the currently executing function at a particula
On Fri, Jun 13, 2014 at 5:42 AM, Frank Millman wrote:
> Now I want to use the functionality of asyncio by using a 'yield from' to
> suspend the currently executing function at a particular point while it
> waits for some information. I find that adding 'yield from' turns the
> function into a gene
Hi all
I am trying to get to grips with asyncio, but I don't know if I am doing it
right.
I have an app that listens for http connections and sends responses. I had
it working
with cherrypy, which uses threading. Now I am trying to convert it to
asyncio,
using a package called aiohttp.
I got
47 matches
Mail list logo
