[Async-sig] Anyone want to take ownership of this mailing list?

[Brett Cannon]

Cory and I are the owners and neither of us are that active in this space,
so it would probably be best if someone else took over.
___
Async-sig mailing list -- async-sig@python.org
To unsubscribe send an email to async-sig-le...@python.org
https://mail.python.org/mailman3/lists/async-sig.python.org/
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [Async-sig] concurrency mistake

[Brett Cannon]

It's because you're awaiting on your tasks in your 2nd example, causing you
to make your main() call wait until each task is complete before moving on
(notice how you don't await in your calls to loop.create_task() in your 1st
example).

I think you want is something like:

import asyncio

async def say(what, when):
await asyncio.sleep(when)
print(what)

async def main(loop):
task1 = loop.create_task(say('first hello (sleep 2 seconds)', 2))
task2 = loop.create_task(say('second hello (sleep one second)', 1))
await asyncio.gather(task1, task2, loop=loop)
print('close')

loop = asyncio.get_event_loop()
loop.run_until_complete(main(loop))
loop.close()


On Mon, 27 Aug 2018 at 02:47 saurabh singh  wrote:

> my question is 1st one is concurrent but 2nd one is not, how and please
> correct me, what i miss and what  should i know more
> thank you
>
> import asyncio
>
> # 1st code
> async def say(what, when):
> await asyncio.sleep(when)
> print(what)
>
> loop = asyncio.get_event_loop()
>
> loop.create_task(say('first hello', 2))
> loop.create_task(say('second hello', 1))
>
> loop.run_forever()
> loop.close()
>
> '''
> result
> >>> second hello
> >>> first hello
> '''
>
> # 2nd code
> async def say(what, when):
> await asyncio.sleep(when)
> print(what)
>
> async def main(loop):
> yield from loop.create_task(say('first hello', 2))
> yield from loop.create_task(say('second hello', 1))
> print('close')
>
> loop = asyncio.get_event_loop()
> loop.run_until_complete(main(loop))
> loop.close()
>
> '''
> result
> >>> first hello
> >>> second hello
> '''
>
> ___
> Async-sig mailing list
> Async-sig@python.org
> https://mail.python.org/mailman/listinfo/async-sig
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [Async-sig] new library: sniffio – Sniff out which async library your code is running under

[Brett Cannon]

Importation does not equate to execution. I.e. since I could have multiple
event loops running at once that means what's in sys.modules can't tell me
what event loop I'm currently interacting with.

On Fri, 17 Aug 2018 at 09:09 Alex Grönholm  wrote:

> This was my approach:
>
> def _detect_running_asynclib() -> str:
> if 'trio' in sys.modules:
> from trio.hazmat import current_trio_token
> try:
> current_trio_token()
> except RuntimeError:
> pass
> else:
> return 'trio'
>
> if 'curio' in sys.modules:
> from curio.meta import curio_running
> if curio_running():
> return 'curio'
>
> if 'asyncio' in sys.modules:
> from .backends.asyncio import get_running_loop
> if get_running_loop() is not None:
> return 'asyncio'
>
> raise LookupError('Cannot find any running async event loop')
>
>
> Is there something wrong with this?
>
> to, 2018-08-16 kello 00:01 -0700, Nathaniel Smith kirjoitti:
>
> Hi all,
>
>
> A number of people are working on packages that support multiple async
>
> backends (e.g., asyncio + trio, or trio + curio, or trio + twisted,
>
> ...). So then the question arises... how can I figure out which async
>
> library my user is actually using?
>
>
> Answer: install sniffio, and then call
>
> sniffio.current_async_library(), and it tells you.
>
>
> Well, right now it only works for trio and asyncio, but if you
>
> maintain an async library and you want to make it easier for packages
>
> to detect you, then it's easy to add support – see the manual. We
>
> considered various clever things, but ultimately decided that the best
>
> approach was to use a ContextVar and make it the coroutine runner's
>
> responsibility to advertise which async flavor it uses. In particular,
>
> this approach works even for hybrid programs that are using multiple
>
> coroutine runners in the same loop, like a Twisted program with
>
> asyncio-flavored and twisted-flavored coroutines in the same thread,
>
> or a Trio program using trio-asyncio to run both asyncio-flavored and
>
> trio-flavored coroutines in the same thread.
>
>
> Github: https://github.com/python-trio/sniffio
>
> Manual: https://sniffio.readthedocs.io/
>
> PyPI: https://pypi.org/p/sniffio
>
>
> -n
>
>
>
> ___
> Async-sig mailing list
> Async-sig@python.org
> https://mail.python.org/mailman/listinfo/async-sig
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [Async-sig] async documentation methods

[Brett Cannon]

Curio uses `.. asyncfunction:: acquire` and it renders as `await acquire()`
at least in the function definition.

On Fri, 30 Jun 2017 at 03:36 Andrew Svetlov 
wrote:

> I like "two methods, `async acquire()` and `release()`"
>
> Regarding to extra markups -- I created sphinxcontrib-asyncio [1] library
> for it. Hmm, README is pretty empty but we do use the library for
> documenting aio-libs and aiohttp [2] itself
>
> We use ".. comethod:: connect(request)" for method and "cofunction" for
> top level functions.
>
> Additional markup for methods that could be used as async context managers:
>
>.. comethod:: delete(url, **kwargs)
>   :async-with:
>   :coroutine:
>
> and `:async-for:` for async iterators.
>
>
> 1. https://github.com/aio-libs/sphinxcontrib-asyncio
> 2. https://github.com/aio-libs/aiohttp
>
> On Fri, Jun 30, 2017 at 1:11 PM Dima Tisnek  wrote:
>
>> Hi all,
>>
>> I'm working to improve async docs, and I wonder if/how async methods
>> ought to be marked in the documentation, for example
>> library/async-sync.rst:
>>
>> """ ... It [lock] has two basic methods, `acquire()` and `release()`. ...
>> """
>>
>> In fact, these methods are not symmetric, the earlier is asynchronous
>> and the latter synchronous:
>>
>> Definitions are `async def acquire()` and `def release()`.
>> Likewise user is expected to call `await .acquire()` and `.release()`.
>>
>> This is user-facing documentation, IMO it should be clearer.
>> Although there are examples for this specific case, I'm concerned with
>> general documentation best practice.
>>
>> Should this example read, e.g.:
>> * two methods, `async acquire()` and `release()`
>> or perhaps
>> * two methods, used `await x.acquire()` and `x.release()`
>> or something else?
>>
>> If there's a good example already Python docs or in some 3rd party
>> docs, please tell.
>>
>> Likewise, should there be marks on iterators? async generators? things
>> that ought to be used as context managers?
>>
>> Cheers,
>> d.
>> ___
>> Async-sig mailing list
>> Async-sig@python.org
>> https://mail.python.org/mailman/listinfo/async-sig
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> --
> Thanks,
> Andrew Svetlov
> ___
> Async-sig mailing list
> Async-sig@python.org
> https://mail.python.org/mailman/listinfo/async-sig
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [Async-sig] [ann] sphinxcontrib-trio: make sphinx better at documenting functions/methods, esp. for async/await code

[Brett Cannon]

So are you going to try to upstream this? ;)

On Fri, 12 May 2017 at 01:24 Nathaniel Smith  wrote:

> Hi all,
>
> I just released a new package, sphinxcontrib-trio:
>
> https://sphinxcontrib-trio.readthedocs.io/
>
> It makes it easier to document many kinds of functions/methods in
> sphinx, including async functions, abstract methods, generators, etc.
>
> I originally wrote it for the trio [1] project, hence the name, but
> don't let that put you off -- there's nothing about it that's specific
> to trio, or even to async/await (except that projects that use
> async/await *really need* an extension like this). Really I think this
> extension ought to be a standard feature of sphinx. But in the mean
> time, it's pretty handy.
>
> -n
>
> [1] https://trio.readthedocs.io
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> ___
> Async-sig mailing list
> Async-sig@python.org
> https://mail.python.org/mailman/listinfo/async-sig
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [Async-sig] Trio: async I/O for humans and snake people

[Brett Cannon]

I assume the name is a reference to the fact that there's now a three-way
competition for ultimate async library? :)

Great work, BTW!

On Fri, 10 Mar 2017 at 19:07 Nathaniel Smith  wrote:

> Hi all,
>
> I'd like to announce the initial release of Trio, a new
> permissively-licensed async I/O library for Python 3.5+.
>
> Blog post with more details:
> https://vorpus.org/blog/announcing-trio/
>
> Or you can jump straight to the repo:
> https://github.com/python-trio/trio/
>
> Cheers,
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> ___
> Async-sig mailing list
> Async-sig@python.org
> https://mail.python.org/mailman/listinfo/async-sig
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [Async-sig] SansIO (Was: PEP: asynchronous generators)

[Brett Cannon]

On Thu, 11 Aug 2016 at 10:23 Antoine Pitrou  wrote:

>
> Hi,
>
> > However, I think we can safely say that the Python community has not
> > effectively done this over our twenty-plus year lifetime.
>
> I'd like to offer a couple remarks here:
>
> 1) implementing a protocol usually goes beyond parsing (which, it's
> true, can easily be done "sans IO").
>

Yes, but parsing the data is at least one of the steps that people have
historically not factored out into a stand-alone library.


>
> 2) many non-trivial protocols are stateful, at least at the level of a
> single connection; the statefulness may require doing I/O spontaneously
> (example: sending a keepalive packet). You can partly solve this by
> having a lower layer implementing the stateless parts ("sans IO") and an
> upper layer implementing the rest above it, but depending on the
> protocol it may be impossible to offer an *entire* implementation that
> doesn't depend on at least some notion of I/O.
>

Also true. While this can either be handled by a state machine emitting
keepalive events or simply telling people they may need to emit something,
this doesn't detract from the fact that at least parsing the data off the
wire can be done as a standalone project (making a state machine that works
for the protocol w/o any I/O will vary from protocol to protocol).


>
> 3) the Protocol abstraction in asyncio (massively inspired from Twisted,
> of course) is a pragmatic way to minimize the I/O coupling of protocol
> implementations (and one of the reasons why I pushed for it during the
> PEP discussion): it still has some I/O-related elements to it (a couple
> callbacks on Protocol, and a couple methods on Transport), but in a way
> that makes ignoring them much easier than when using "streams", sockets
> or similar concepts.
>

Yep. Once again, no one is saying that a I/O-free approach to protocols
will work in all situations, but it should be considered and in cases where
it does work it's good to have and can be used with asyncio's ABCs.

IOW you're totally right that I/O-free protocol libraries will not always
work, but sometimes they do and people should thus consider structuring
their libraries that way when it makes sense.
___
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/