Mailman 3 - Async-sig

Is the RIG 700HX good? Can you Connect RIG 700HX to phone?
by jacklesner046＠gmail.com Oct. 17, 2022

Oct. 17, 2022

While the RIG 700HX may play it diffused in terms of how it looks and feels, it’s in the various high-quality-of-existence functions in which it packs the maximum punch. All the expected gaming headset heavy hitters are right here and then a few, justifying it nevertheless honest however now not insignificant $a hundred thirty / £119 fee. The RIG 700HX can provide a long lasting, ultra-light-weight wireless gaming headset. Choose the perfect levels that be just right for you with a sport/chat balance dial and adjustable mic tracking. And with Dolby Atmos®, you’ll experience effective, shifting audio that sweeps all round and above you. For game enthusiasts searching out a wireless console and PC gaming headset near the $a hundred range, Plantronics has these days launched a $129.99 product that you may need to recollect. We liked the remaining headset they produced in this realm, the RIG 800LX, which went for $one hundred fifty and gave you a strong wireless answer for the Xbox One and PC. However, the RIG 700HX brings the charge even lower whilst endeavouring to provide you with practically the equal first-class and enjoy because the RIG 800LX. Also, like the 800LX, the RIG 700HX is available in Xbox One/PC and PS4/PC models. Table of Contents Does RIG 700HX have Dolby Atmos? Can you use RIG 700HX in your PC? Does RIG 700HX have Bluetooth? Does RIG 700HX have Dolby Atmos? The construct of the RIG 700HX takes the merits of the RIG headset line under consideration on this cutting-edge model. First, you've got a plastic headscarf with a cushioned cloth mesh resting in your head. The ear cups mouth a cushion layout that I’m satisfied to look in greater and more headsets in recent times. That is to mention. The pillows employ a material and imitation leather hybrid skin, in which the fabric mesh comes in interplay along with your pores and skin, and the encircling leather-based assists in attaining a stable acoustic seal. Ear cup placement and headset adjustment have a completely unique twist right here, as with many different RIG headsets, where the ear cups stay located into three top slots. In addition, ear cups may be popped and snapped back into a fixed headscarf at three-length locations.@https://www.clubhitech.com/rig-700hx/

1 0

Listening for OS events
by J.P. Hutchins Oct. 1, 2022

Oct. 1, 2022

Greetings! I would like to modify/replace an existing library, pySerial, to use asyncio in Windows/Mac/Linux. I have a Windows implementation working by "listening for an event" like this: read_future = loop._proactor.wait_for_handle(overlapped_read.hEvent) Where overlapped_read is the OVERLAPPED structure <https://docs.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase…> (via ctypes or pywin32) and the event is setup previously, e.g. "received chars on the serial port" event here. My question is in regards to the best practices for awaiting an OS event providing for the most efficient and maintainable implementation. Reference to other multi-platform libraries or builtins that accomplish similar would be appreciated. Thanks for your time, J.P. Hutchins

3 4

DEMO-2345 Re: Listening for OS events
by Demo service project Sept. 29, 2022

Sept. 29, 2022

—-—-—-— Reply above this line. Just confirming that we got your request. We're on it. View request: https://jirahieu.atlassian.net/servicedesk/customer/portal/2/DEMO-2345?toke… Turn off this request's notifications: https://jirahieu.atlassian.net/servicedesk/customer/portal/2/DEMO-2345/unsu… This is shared with async-sig(a)python.org ------------------------------ Powered by Jira Service Management https://www.atlassian.com/software/jira/service-desk/powered-by?utm_medium=…

2 1

Re-purposing WSGI standard, PEP 3333, for use in callback based async backends.
by TobiasHT April 28, 2022

April 28, 2022

Asynchronous programming in python has become popular in the past few months. Quite a number of frameworks and servers have been developed to take advantage of this python feature. With the development of numerous such tools in python, a standard needed to be set to streamline their development by setting a common interface to implement, and hence the ASGI standard was born. The ASGI standard is holding up quite well when it comes to ease of implementation and general popularity. However, it imposes the use of coroutines in almost everything, which I feel is a design constraint in some way. PEP 3156 suggests that one can use asyncio with either callbacks or coroutines and does not favor one pattern over the other, but the continued use of only coroutines in many of the existing tools due to the constraint imposed by ASGI is limiting the use of the callback pattern, which is quite easier in my opinion, and achieves a similar level of concurrency. So my suggestion is to repurpose the existing WSGI standard, PEP 3333 in order to incorporate the aspect of callback based concurrency. I feel it would be much easier than redesigning the ASGI standard since WSGI doesn’t use coroutines in the first place. I assume it would also be easier for the existing WSGI based tools like Flask, Django, bottle and others to implement, and it would probably be much more efficient than their existing efforts to migrate to ASGI standard. It would also in a way bridge a gap between the async and sync worlds since this is one of the topics that gives us a headache. It’s evident that I have not thought everything through. I was just waiting for people’s reaction to this idea before I can proceed any further with it. One of the problems that this idea will face will be the conflict between WSGI and ASGI yet ASGI is trying to phase out WSGI. The other perhaps would be that many parts of asyncio, especially those connected to networks, are coroutines. Those are my thoughts however, I wonder what everyone else’s thoughts on this are.

1 0

correct way to combine two coroutines in a loop
by Sven R. Kunze July 14, 2021

July 14, 2021

Hey everyone, I hope this is the right mlist to post my question to. If not, please redirect me to the correct one. I recently tried async for websockets. Here's the question: Looking at the following code, is there a better way to do it? I personally find it much too much code for its purpose. Yet I cannot think of an improvement because I am not used to the usual patterns in async programming. What I find especially annoying is the boilerplate code regarding the renewal of the consumed task object (initializing with None, picking the last one or create a new one, resetting to None, repeat). If, due to the boilerplate, the intent is not clear, there are two endlessly producing coroutines ("queue" & "receive") from which is being read and reacted to, whatever comes first. notify_task = None event_task = None while True: notify_task = notify_task or asyncio.Task(queue.get()) event_task = event_task or asyncio.Task(receive()) done, pending = await asyncio.wait([notify_task, event_task], return_when=asyncio.FIRST_COMPLETED) if notify_task in done: notify = notify_task.result() notify_task = None await handle_notify(scope, send, notify) if event_task in done: event = event_task.result() event_task = None if await handle_ws_default_protocol(scope, send, event, conn, listen_callback): break Why am I asking? Because a friend of mine also was a bit puzzled that this "select.select"-type of programming is so verbose in async or if we were just missing a crucial element. Cheers and thanks you in advance for any answer, Sven PS: What's the history of this code? Reading different tutorials, both queues are discussed and implemented separately (one is websocket, the other one is a message broker). Either code examples were quiet small. But as soon as you want to plug both together, the resulting code suddenly explodes and requires a lot of manual handling as shown above. At least from my perception of "manual". I do not blame these tutorials as they focus on either problem separately. Still in real-world projects, different concepts frequently need to be combined to make the whole idea work. It took me quite some time to find a way to do it. The result above, I find it neither readable nor explainable to other async-noobs like me. Especially "asyncio.wait" was quite hidden in the library (and from google) and it took me many iterations to understand how to interact with it properly (although the obvious API is quite simple).

3 2

Anyone want to take ownership of this mailing list?
by Brett Cannon July 13, 2021

July 13, 2021

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.

2 1

get_event_loop() repl support for sync->async constraints
by Blaze Spinnaker Oct. 23, 2020

Oct. 23, 2020

Upfront apologies if this email is late to the party and we've overlooked previous closure / guidance on this subject. If there is a resolution here, please provide an authoritative link. I will make sure to share it broadly as I am talking with a few other folks wondering about the same thing. Perhaps adding a link to the asyncio docs would be good too. -- Please See here - https://github.com/ipython/ipykernel/issues/548#issuecomment-713637954 The issue is that folks write code, and then may (or may not) try to execute that code in the context of a repl. That repl may (or may not) have an asyncio event loop already running. Sometimes one repl may not be sufficient, and others may decide to move onto another repl. There are many repls in the ecosystem. They all satisfy different needs and requirements. And in fact, we are writing a new one as well which takes a more visual approach than previous ones. It will not be based on iPython or jupyter. Repls are very critical to the success of python, especially in the realm of data science and notebooks, which has lead to a great deal of industry investment. Usually these users are not engaged or concerned about the subtleties of Python itself, they want it to just simply work. It usually does, which makes Python great for this use case. But in writing our own repl, we are faced with an issue everyone else is who makes a repl like solution - what is the asyncio contract for executing asyncio code within the context of a repl? Note that configuring the environment or cherry picking the right asyncio code to execute in the right context is not a user friendly solution. This is not how repls are generally used, and goes against their value proposition of just working. There should be a way to call code which will work on both async and sync contexts while minimizing behavioral differences. Ideally, we would have an agreed upon asyncio API we can run in repls that works in either context. I've seen in a few places folks have solved this problem by fudging their execution environments a bit and suggesting using asyncio.get_event_loop().run_until_complete, however the documentation for asyncio specifically discourages the use of this API. Some environments do sub optimal (IMHO) like allowing await outside the context of an async API. I imagine this will inevitably lead to confusion, though I agree it's tricky to disallow. The solutions out there currently are not very solid and only work in inconsistent circumstances, which is not surprising as there is no contract here. For example, calling asyncio.run() can break the api above. However, the solution is actually reasonable and we will use the get_event_loop() API if that is the consensus. So, second question - If using get_event_loop().run_until_complete() is the right way is it possible to add something to the documentation to this effect to provide some reassurance to both repl dev and users that efforts will be made to avoid breaking this? It can also be used to inform other folks about the 'right way'. Some maintainers are recommending monkey patching, which leads to poor outcomes. Even better would be to add implementation support for this, but I don't have high expectations there. Guidance on how best to support it and what will be forwards compatible would be nice, tho. It doesn't have to be forever, but it would be good to have at least some documented if temporary agreement among the language/stdlib designers and the repl community. Fwiw, if there is no consensus opinion on a non intrusive solution, likely we will default and follow suit of other repls and defacto support get_event_loop().run_until_complete(). Not ideal, in my honest opinion, but practical.

1 0

PR's re: asyncio troubleshooting / tracebacks
by Chris Jerdonek May 8, 2020

May 8, 2020

Hi folks, I wanted to raise visibility about a few asyncio PR's I'm hoping can be merged before the 3.9 beta deadline -- which is ~10 days away. The four PR's are listed at the end of this message. The PR's are on the simple side compared to others. I think collectively they can make asyncio a lot easier to use and troubleshoot. This is because they address various situations where parts of the traceback or stacktrace can go missing in asyncio, which makes issues a lot harder to pin down. The issue of incomplete tracebacks was probably the biggest pain point for me when I was starting out with asyncio. Like, here's an email I sent to this list two and a half years ago: https://mail.python.org/pipermail/async-sig/2017-November/000403.html Below are the four issues, in the order in which I think they should be reviewed (in order of both simplicity and impact, in my estimation): 1) bpo-29587: Enable exception chaining for gen.throw() with "yield from": https://github.com/python/cpython/pull/19858 This PR addresses a third example of the following bpo issue (not one of the two listed by Nathaniel, but with the same root cause as the others): https://bugs.python.org/issue29587 This aspect causes parts of the traceback to go missing / be swallowed in certain situations if an exception happens while awaiting an async task. 2) bpo-31033: Full tracebacks for cancelled asyncio tasks: https://github.com/python/cpython/pull/19951 This is a big one because currently, the traceback for cancelled tasks shows almost nothing. This PR would show a traceback starting with what code got interrupted, and how the exception bubbled up from there. It's one aspect of the following issue about making cancelled tasks easier to diagnose: https://bugs.python.org/issue31033 3) bpo-29590: fix stack trace for gen.throw() with yield from https://github.com/python/cpython/pull/19896 This is a second issue that Nathaniel filed: https://bugs.python.org/issue29590 It's about how stack trace entries get lost if you're trying to profile asyncio code. 4) bpo-31033: Add a msg argument to Future.cancel() and Task.cancel() https://github.com/python/cpython/pull/19979 This PR would let you pass a "msg" to cancel(), which would show up in the traceback as the CancelledError's message. This is the other side of #2 (bpo-31033) because it would let you record _why_ a task was cancelled, or other details (as opposed to seeing _what_ got cancelled). Thank you, --Chris

1 0

Yet
by Thắng Phạm April 19, 2020

April 19, 2020

Cadtme(a)zohomail.com

1 0

Async stack "backtrace"
by Dima Tisnek Aug. 8, 2019

Aug. 8, 2019

Hi group, I'm recently debugging a long-running asyncio program that appears to get stuck about once a week. The tools I've discovered so far are: high level: `asyncio.all_tasks()` + `asyncio.Task.get_stack()` low level: `loop._selector._fd_to_key` What's missing is the middle level, i.e. stack-like linkage of what is waiting for what. For a practical example, consider: async def leaf(): await somesocket.recv() async def baz(): await leaf() async def bar(): await baz() async def foo(): await bar() async def job(): await foo() async def work(): await asyncio.gather(..., job()) async def main(): asyncio.run(work()) The task stack will contain: * main and body of work with line number * job task with line number pointing to foo The file descriptor mapping, docket fd, loop._recv() and a Future. What's missing are connections foo->bar->baz->leaf. That is, I can't tell which task is waiting for what terminal Future. Is this problem solved in some way that I'm not aware of? Is there a library or external tool for this already? Perhaps, if I could get a list of all pending coroutines, I could figure out what's wrong. If no such API exists, I'm thinking of the following: async def foo(): await bar() In [37]: dis.dis(foo) 1 0 LOAD_GLOBAL 0 (bar) 2 CALL_FUNCTION 0 4 GET_AWAITABLE 6 LOAD_CONST 0 (None) 8 YIELD_FROM 10 POP_TOP 12 LOAD_CONST 0 (None) 14 RETURN_VALUE Starting from a pending task, I'd get it's coroutine and: get the coroutine frame, and if current instruction is YIELD_FROM, then the reference to the awaitable should be on the top of the stack. If that reference points to a pending coroutine, I'd add that to the "forward trace" and repeat. at some point I'd reach an awaitable that's not a pending coroutine, which may be: another Task (I already got those), a low-level Future (can be looked up in event loop), an Event (tough luck, shoulda logged all Events on creation) or a dozen other corner cases. What do y'all think of this approach? Thanks, D.

1 0