> On Jul 6, 2016, at 9:44 PM, Nathaniel Smith wrote:
>
> On Wed, Jul 6, 2016 at 6:17 PM, Yury Selivanov wrote:
>>
>>> ...does it actually work to re-enter a main loop from inside a __del__
>>> callback? It seems like you could get into really nasty states with
>>> multiple nested __del__ calls
On Wed, Jul 6, 2016 at 6:17 PM, Yury Selivanov wrote:
>
>> ...does it actually work to re-enter a main loop from inside a __del__
>> callback? It seems like you could get into really nasty states with
>> multiple nested __del__ calls, or if a single sweep detects multiple
>> pieces of garbage with
> ...does it actually work to re-enter a main loop from inside a __del__
> callback? It seems like you could get into really nasty states with
> multiple nested __del__ calls, or if a single sweep detects multiple
> pieces of garbage with __del__ methods, then some of those __del__
> calls could b
On Wed, Jul 6, 2016 at 5:47 PM, Glyph Lefkowitz wrote:
>
> On Jul 6, 2016, at 5:25 PM, Yury Selivanov wrote:
>
> The problem is that the GC can’t execute async code, and we don’t have any
> control over GC. What if we add a mechanism to control how async generators
> (AG) are destructed. Let’s
> On Jul 6, 2016, at 8:47 PM, Glyph Lefkowitz wrote:
>
>
>> On Jul 6, 2016, at 5:25 PM, Yury Selivanov wrote:
>>
>> The problem is that the GC can’t execute async code, and we don’t have any
>> control over GC. What if we add a mechanism to control how async generators
>> (AG) are destruc
> On Jul 6, 2016, at 5:25 PM, Yury Selivanov wrote:
>
> The problem is that the GC can’t execute async code, and we don’t have any
> control over GC. What if we add a mechanism to control how async generators
> (AG) are destructed. Let’s say we add new function to the sys module -
> `sys.se
> On Jul 6, 2016, at 7:06 PM, Nathaniel Smith wrote:
>
> On Wed, Jul 6, 2016 at 1:12 PM, Yury Selivanov wrote:
>> This is an interesting idea, but I wonder if instead of using ‘async with’
>> we can actually augment ‘async for’ to do the async finalization.
>>
>> We can add an __aiter_close__
On Wed, Jul 6, 2016 at 1:12 PM, Yury Selivanov wrote:
> This is an interesting idea, but I wonder if instead of using ‘async with’ we
> can actually augment ‘async for’ to do the async finalization.
>
> We can add an __aiter_close__ special method which will return an awaitable.
> In this case,
I tried to implement asyncronious generators based on asyncio recently,
you can see result here:
https://github.com/germn/aiogen
I also faced problem with cleanup.
First thing is where to call `.close` (or async `.aclose` for AG since
it raises exception inside async function). While regular
> On Jul 6, 2016, at 3:54 PM, David Beazley wrote:
>
>
>> However, as far as I know curio doesn’t have the ability to schedule an
>> operation in a synchronous manner by means of something like a Future. Is
>> that correct? If there is no way in curio to spawn a task to occur later
>> withou
> However, as far as I know curio doesn’t have the ability to schedule an
> operation in a synchronous manner by means of something like a Future. Is
> that correct? If there is no way in curio to spawn a task to occur later
> without having to await on it, then clearly there is no option but t
On Wed, Jul 6, 2016 at 6:42 AM, Cory Benfield wrote:
>
>> On 6 Jul 2016, at 13:09, David Beazley wrote:
>>
>> Curio uses asynchronous context managers for much more than closing sockets
>> (which frankly is the least interesting thing). For example, they're used
>> extensively with synchroniz
> On Jul 5, 2016, at 5:56 PM, Nathaniel Smith wrote:
>
> Starting axiom: async functions / async generators need to be prepared
> for the case where they get garbage collected before being run to
> completion, because, well... this is a thing that can happen.
This thread is really confusing, so
> On Jul 5, 2016, at 8:56 PM, Nathaniel Smith wrote:
[..]
> Starting axiom: async functions / async generators need to be prepared
> for the case where they get garbage collected before being run to
> completion, because, well... this is a thing that can happen.
[..]
> Dismaying conclusion: insid
> On 6 Jul 2016, at 13:09, David Beazley wrote:
>
> Curio uses asynchronous context managers for much more than closing sockets
> (which frankly is the least interesting thing). For example, they're used
> extensively with synchronization primitives such as Locks, Semaphores,
> Events, Queu
Cory wrote:
"What’s not entirely clear to me is why we need __aexit__ to *actually* be an
async function. The example in curio is socket closure, which seems to be like
it absolutely does not need to be awaitable."
Curio uses asynchronous context managers for much more than closing sockets
(wh
> On 6 Jul 2016, at 01:56, Nathaniel Smith wrote:
>
> There's some more discussion, and a first sketch at conventions we
> might want to use for handling this, here:
>
>https://github.com/dabeaz/curio/issues/70
This feels like a problem with very few good solutions.
Finalizers (e.g. __del
So here's an interesting issue I just discovered while experimenting
with async generators. It caught me by surprise, anyway. Maybe this
was already obvious to everyone else. But I wanted to get some more
perspectives.
Starting axiom: async functions / async generators need to be prepared
for the
18 matches
Mail list logo
