Software developers should avoid traumatic changes
@sir I thought asyncio will be removed in the future (https://charlesleifer.com/blog/new-features-planned-for-python-4-0/). 😉
@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.
@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.
@minus have you tried parsing pg_xlog? :P
@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
@minus pg_xlog *is* the WAL.
@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?
@YaLTeR do not know
@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 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?
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!