busybee fluffy rambles Notes

asyncio generally requires that you provide a “session”/“client” object that contains the run loop for the async operations. I think that when you refactor a library to support asyncio, you provide a non-async wrapper around it which spins up the execution loop for each operation, although there might be a better pattern for it these days.

An antipattern I’ve seen a lot is people wrapping a non-async library in a threadpool and then have the async wrapper block on the future, but that completely misses the point to asyncio and makes everything perform way worse.

asyncio is kind of wonky to wrap your head around at first but it’s well worth it for the major performance gains you get. It can be a huge pill to swallow though, and given that most Python web apps are still running in a thread-per-connection context (because wsgi is designed around it) it can feel like a chicken-egg scenario at times. But doing the work of moving to asyncio (and providing a non-async wrapper around it) makes it easier for more things to move to asyncio and getting the performance benefits as a result, so it’s a net good IMO, even if it isn’t heavily used right away.

Indieweb Utils looks pretty neat and there’s a few projects I’ve had on the backburner which would benefit from this.

I’d also be pretty tempted to look into moving Pushl over to it, just to cut down on my own code maintenance requirements, except it looks like it doesn’t have any support for asyncio, which is less-than-optimal for an I/O-bound tool which sends a bunch of bulk updates. Is there any interest in adding asyncio support?

A conversation of sorts about how modern social media helps to amplify some of the worst aspects of toxic discourse. Possibly educational for straight allies, too.

jamesg asks:

How much coffee do you drink in a day?

I usually drink 1-2 shots of espresso per day, so “1 cup” feels like the closest match.

Most of it is decaf, though.

@jamesg:

I am intrigued by the IndieWeb’s approach to plurality and building technologies that don’t serve the creation of monocultures or single ways of thinking about things. IndieWeb technologies help build plug-and-play social bridges. The technologies are your pipes. You get to decide how they connect and what you make with those pipes. This idea excites me to a great degree.

Could you explain what you mean by “plurality?” In the circles I run in it almost certainly means something different than what you mean by it, and the definition I’m familiar with is likely to be the more common one on the Internet in 2020 2022.

From context it seems like you’re talking about building a (distributed) voting/polling system, which is definitely an interesting topic to think about, and the first-cut approach would probably be to do something using fragmentions or otherwise having a u-vote-for (or similar) link either to an anchor on the page or to the resource being voted on (e.g. the image itself).