@cedricbonhomme @sir Wait, they actually recommend gevent? Imo gevent is fairly fragile (if you're calling (native) code that does not support gevent it will just hang) and hardly anyone uses it. It's tacked on, just like asyncio, though at least integrates better.

To be a good solution it would have to be a first party thing. The way gevent works is imo the superior solution.

@minus @sir last time used gevent seriously it was probably around 2013-14.
I am now using asyncio but for basic things.

@cedricbonhomme @sir Oh, I didn't read it from the start and thus didn't see it was a joke. My point stands though

@Wolf480pl I've used gevent, asyncio and Twisted. Thinking about it, I wrote a database replication daemon and client with Twisted for work years ago. It was fairly nice to use iirc. This was pre-asyncio, but it already had @deferredCallback or whatever it's called (aka same thing that asyncio now uses, except still with yield keyword and generators). (That piece of software has since been replaced by a small piece of Java)

@Wolf480pl avsd, 2014-07 - 2017-04, you will not be missed. Turns out that building a Python daemon that connects to Postgres to listen for NOTIFYs and reads changes from log tables filled with DB triggers, only to generate Redis commands and write them to another Redis so that a second Python daemon can fetch those commands and execute them on another Redis instance isn't the most reliable way to do replication.

Writing DB replication tooling is hard, don't do it, kids. Though our current approach works reliably (constraint triggers + a couple hundred lines of Java + a replication definition file). Might open source maybe. Doubt it's gonna be terribly useful. It's essentially what slony also does.

@Wolf480pl If I'd ever do it again, that's probably where I'd start. Having DB triggers log shit is terrible and makes things slow. (Well, not as much as certain other triggers)

@Wolf480pl Well, WALs i mean. Didn't know about pg_xlog, might be worth a shot? If only for shits and giggles

@Wolf480pl Ah sorry, I was looking at this:

pg_xlogdump -- display a human-readable rendering of the write-ahead log of a PostgreSQL database cluster

@minus yeah, so you'd have to do something like reimplementing pg_xlogdump but better.

@sir How could they have handled asyncio better in your opinion?

@sir Ouch (working with Flask, SQLAlchemy). Still feeling this one creeping up but I've only been working with Python since the change to 3 was already well underway... You're right though; the pace of change may keep podcasters in work etc., but is traumatic for most.

@sir I understand your point but I found it naive and/or unsustainable. No tool, no framework, no piece of software can be made perfect the first time around nor should be expected to be. Because we aren't perfect and have limited resources, especially in the FLOSS world. Communities build around those imperfect things and adapt and work around their limitations to achieve their own goals.

But in sufficiently complex systems, change is inevitable because not everything can reasonably be well thought out from the get go. And inevitably some people won't like it, because they specifically designed their work environment/software/workflow around existing, familiar things, even imperfect. And the pushback doesn't always come from specific design concerns, sometimes it's just resisting change because of the potential loss of comfort/convenience.

The problem of putting the onus of designers is that they can't possibly account for all use cases for something that doesn't exist yet. This is humorously addressed in one of XKCD comics: xkcd.com/1172/

Ultimately, change friction is just inevitable, can't be prevented even with any arbitrary amount of thinking and is no one's fault. Code rot isn't a property of the code itself in isolation, but relative to a changing environment. Even in your example, the addition of asyncio to Python doesn't make SourceHut not working anymore, you're just disappointed that you didn't have it in the first place and now it's going to be logically expensive to rewrite it.

But there is absolutely nothing the Python language designers could have done to prevent this disappointment. The same is true for Python 2/Python 3. All of Python 2 code will still work with a Python 2 runtime, even after its end of life. You are recognizing the value of Python 3, which means that I expect you to understand that support for Python 2 had to end at some point.

I hear your loss of convenience, but your suggestion on how to prevent it is misled. You have to reconcile yourself with this lack of convenience in a fast-moving environment, because no one else can possibly engineer it away for you.

@sir This is a good observation, and I wonder how it relates to the question of batching together changes vs. piecemeal change throughout an ecosystem. In some ways, the Python 2 -> 3 transition was survivable because you could say "Python 2" and it meant that your code still worked the same. It may have been worse if the individual changes were not all caught up by the same umbrella migration.

Would having a concretely identified pre-asyncio ecosystem and post-asyncio ecosystem be helpful?

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!