"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
35 matches
Mail list logo
