Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 25 10:39
    gschaffner commented #526
  • Jan 25 09:11
    gschaffner commented #525
  • Jan 24 17:07
    uSpike closed #526
  • Jan 24 17:07
    uSpike commented #526
  • Jan 24 16:34
    agronholm commented #526
  • Jan 24 16:33
    agronholm commented #526
  • Jan 24 16:29
    uSpike commented #526
  • Jan 24 15:28
    agronholm commented #374
  • Jan 24 15:26
    reidmeyer commented #374
  • Jan 24 15:22
    agronholm commented #374
  • Jan 24 15:15
    smurfix commented #374
  • Jan 24 15:09
    reidmeyer commented #374
  • Jan 24 15:04
    agronholm commented #374
  • Jan 24 10:36
    reidmeyer commented #374
  • Jan 24 09:00
    agronholm commented #526
  • Jan 24 00:13
    uSpike edited #526
  • Jan 24 00:13
    uSpike opened #526
  • Jan 18 21:49
    agronholm commented #525
  • Jan 18 02:51
    gschaffner edited #523
  • Jan 18 02:51
    gschaffner edited #525
graingert
@graingert:matrix.org
[m]
You'd create a nursery responsible for reporting errors start reporting tasks in that
So you'd be like
async with reporter() as r:
    async def some_thing()
        try:
            await foo()
        except BaseException as e:
            r.report(e)
    ...
Michael Adkins
@madkinsz
Ah I see, requires a reporter to be passed around. Right now we have a async with report_crashes(): ... which captures and reports on a wide range of errors. It's actually outside the our cancel scope so we don't normally need shielding but we don't have control over how the user is running their event loop so there may be a cancel scope outside of our code and we need to report that failure still.
graingert
@graingert:matrix.org
[m]
That's the cleanest way of doing that
But you can use a contextvar to pass stuff through code that doesn't know about your reporter tool
If the user cares about error reporting they should open an async context manager for you to run a nursery to handle that in
graingert
@graingert:matrix.org
[m]
Yeah there should always be a place where a user of @madkinsz: library can introduce an async with above their cancellation
Michael Adkins
@madkinsz
That makes sense. Our async users are most likely to be the ones that are capable of doing so as well. What's the downside to the shielded cancel?
Alex Grönholm
@agronholm
it could indefinitely delay the enforcement of the cancellation
I prefer setting a reasonable timeout with move_on_after(..., shield=True):
Alex Grönholm
@agronholm
just spent another night fighting that last failing cancellation test
no success :(
Nicolas Epstein
@nilueps
i'm currently porting an asyncio program to anyio, is there a wait to start an async task in a sync scope in a similar fashion as with asyncio.create_task(coro)?
graingert
@graingert:matrix.org
[m]
Yeah you use TaskGroup.start_soon
Nicolas Epstein
@nilueps
TaskGroup itself or a TaskGroup() instance?
graingert
@graingert:matrix.org
[m]
an instance
Nicolas Epstein
@nilueps
ok that's what i figured... for deeply nested calls, is there a way to recover the encapsulating tg, or is it necessary to drill down through the call stack passing along the instance?
Alex Grönholm
@agronholm
@nilueps you could use a context variable, but I'm not sure that's a great idea from a code readability standpoint
Nicolas Epstein
@nilueps
I agree... I think I'm going to have to rethink the program architecture a bit. Thanks for the help
graingert
@graingert:matrix.org
[m]
@nilueps: out of interest what's the program?
it's a mess, don't judge xD
Tobias Alex-Petersen
@tapetersen
Is there a reason TaskGroup.start_soon is annotated to require a Coroutine and not accept a general Awaitable (asking because I want to schedule an async generators aclose method which is an awaitable and get type complaints (it seems to work in this case and I can cast it to fix the "error")
Or rather it needs a Callable returning a Coroutine but couldn't that still be loosened to an Awaitable?
Alex Grönholm
@agronholm
@tapetersen this has been changed in the upcoming v4.0
8 replies
in master we accept any awaitables
Nicolas Epstein
@nilueps
Why can't I pass keyword arguments to start/start_soon?
graingert
@graingert:matrix.org
[m]
I think it predates positional only arguments
Nicolas Epstein
@nilueps
predates?
Michael Adkins
@madkinsz
That's what they do in the Python stdlib — keyword arguments are reserved for settings that are passed to the event loop (or similar) itself.
With positional only arguments, you could do a more elegant interface, but those were added later. https://peps.python.org/pep-0570/
Nicolas Epstein
@nilueps
interesting, ok. thanks for the info!
Alex Grönholm
@agronholm
how would positional-only arguments help?
@nilueps you could just use a lambda
Nicolas Epstein
@nilueps
yeah that's what i ended up doing
thanks
Michael Adkins
@madkinsz
I'm not sure haha I was just trying to guess at graingerts intent.
graingert
@graingert:matrix.org
[m]
Also it predates ParamSpec
Michael Adkins
@madkinsz
ParamSpec won't let you extend with any "special" keyword arguments either though — which is a big bummer.
Jordan Speicher
@uSpike
any interest in a "BufferedTextReceiveStream", basically an analog to "BufferedByteReceiveStream" but for strings? i need this for my app, but thought maybe I could make an anyio MR if useful
    s, r = anyio.create_memory_object_stream(float('inf'), item_type=str)
    bt = BufferedTextReceiveStream(r)

    with s, r:
        await s.send("foo")
        assert await bt.receive() == "foo"
        await s.send("bar")
        assert await bt.receive_exactly(1) == "b"
        assert await bt.receive_exactly(2) == "ar"
        await s.send("baz")
        assert await bt.receive_until("a", 100) == "b"
        assert await bt.receive_exactly(1) == "z"
Marcelo Trylesinski
@Kludex
Good morning :wave:
pytest-asyncio has unused_tcp_port fixture. Which I'm not sure why it exists there... But is it interesting for AnyIO to have it as well?
Alex Grönholm
@agronholm
@Kludex are you saying that anyio should have it too?
Marcelo Trylesinski
@Kludex
I'm more asking if it makes sense for anyio yo have it, rather than suggesting
I think it doesn't make sense for pytest-asyncio to have it, but as it have, does it make sense for anyio to have it as well?
(has*)
Alex Grönholm
@agronholm
probably yes, but also probably under a different name
so as not to conflict with pytest-asyncio
that thing is trivial to implement
I think even anyio's test suite uses something like that internally