-
So this means whatever you write in python today, you will have to re-write it again in 8 years ?
https://en.wikipedia.org/wiki/History_of_Python#Version_release_dates
Maybe tools like 2to3 make it easier though…
-
Guido has shared this article stating that no more breaking changes are expected in the future :
a 4.0 will presumably still happen some day, and the premise of this article is expected to hold for that release: it will be held to the same backwards compatibility obligations as a Python 3.X to 3.X+1 update.
-
-
Basically none of the Python community wants to experience the 3.0-style backwards compatability issues again (this includes core developers).
Something that might get lost in the noise, but 3.0 in particular broke a huge amount and there was relatively little concern for having code that could run in 2+3. But after the feedback they had introduced stuff back into 3 (like allowing the no-op
u'..') and made it easier to run both-version-compatible code. So 3.0 was especially broken.Guido has said that any compatability breakage nowadays would happen piecemeal, and with more care to this issue. Presumably it would have been something like “string literal changes” in one release, “urllib changes” in another release, etc. Instead of forcing all changes all at once.
-
-
-
-
When I migrated 8 projects from python 2.7 to 3.4 (few years ago now) it only took me about a day, it really wasn’t as painful as it was made out to be. Before any big changes are planned the documentation usually suggests ways to structure current code that won’t break future releases.
-
-
-
-
-
I’d be suprised if they were to actually include a switch, which would any python2 interpreter just immediately quit whenever it’s started after 1/1/2020. But guessing that they won’t do that, I’d suppose that most people will be allowed to keep on using the interpreter, even if it isn’t maintained anymore.
-
-
For my own projects I use cron exclusively.
At work we use cron for system-level tasks (e.g. backups) and Celery for application-level tasks (e.g. periodically poll inventory from warehouses), with RabbitMQ as its backend.
Also, think about monitoring those tasks, especially backups. A lot of people don’t and it’s a recipe for disaster. I have started using https://cronhub.io/ recently but there are other similar services such as https://cronitor.io/, or you can roll your own like I used to do.
I would like to second this post.
The programming language/framework specific scheduling parts don’t matter all that much, but the message bus/backend parts do. RabbitMQ and other AMQP solutions are pretty good, try avoiding a simple key-value store based backend such as Redis.
Any specific reason for avoiding Redis/key-value stores? I’ve only had one such experience (resque-php) and the main downside seemed to be the need for polling, but honestly I don’t know if that’s because of Redis or because of resque-php’s implementation. I’d like to hear more about that!
It’s too simplistic. I mean it works for very basic usage, but once you start caring about things like HA or backups or wider usage (so multiple vhosts in rabbitmq terminology) or logging/monitoring it kind of shows how inadequate it is.
Redis clustering is not that nice. Introspectability - it’s on the wrong level, you don’t generally care about the key/value parts, you care more about the message bus parts and since Redis isn’t aware of that it can’t help you with it.