One must imagine Sisyphus happy. Python just loves to break working code on a regular basis with its new releases. If your code is protected from untrusted user data and the internet, Python 2 is actually a really nice language that doesn't constantly force rewrites.
Oh, you want to know the naive UTC datetime in Python, to interface with something like PostgreSQL that recommends naive times? Back in the old days, a simple datetime.datetime.utcnow(). Now days, you need something like:
try:
from datetime import UTC as tz_UTC
except ImportError:
from pytz import UTC as tz_UTC
dt = datetime.datetime.now(tz_UTC).replace(tzinfo=None)
> Oh, you want to know the naive UTC datetime in Python, to interface with something like PostgreSQL that recommends naive times?
Postgres never recommended naive datetimes. A TZ-aware datetime is semantiacally the same as a tuple of (<location/agreed offset>, <time in the moment since unix epoch defined in terms of UTC>). Those who recommended dropping the knowledge of the first part from that pair did it because they didn't know better.
It's a perfectly fine strategy in some situations to only store UTC in the database and handle time zones on display. It's your database, you know what's in there. As an added bonus it allows easily flagging non-UTC timestamps as errors on some level to make sure you don't get tangled up in time zones.
> It's your database, you know what's in there. As an added bonus it allows easily flagging non-UTC timestamps as errors on some level to make sure you don't get tangled up in time zones.
I think you're mixing rendering (and for that matter - time ordering) with the initial information providing, that is a precise data input that doesn't rely on anything external.
Postgres ALWAYS stores timestamps in UTC [1]. When you submit data for persistence from your application, you have a choice of either:
- informing the DB about the recorded location/offset at the point of persistence (even if it's the zero offset) so that the input conversion happens without any reliance on the underlying OS-level or configuration setting [2]
- or omitting that information and therefore 1) losing precision at the point of data input and 2) delegating the location/offset inference for the internal purpose of Postgres to the external global configuration: both side-effects are bad from consistency/reliability perspectives.
I've never seen a single application that would win anything from (2) compared to explicitly providing the offset of the observed moment, even if the entire business domain is in UTC at all times. In fact, I've seen many business applications that explicitly record the offset in a separate column next to the provided timestamps for any future analysis and retrieval. And it's partly by design of the underlying abstractions: the unix epoch is defined in terms of UTC too, so when you design your program around implicit UTC you are not gaining much - the offset information is still there, it's just your data types don't make it clearly visible to everyone. But the moment you start integrating your data with the real world that cares about global time ordering of your recorded data events, you get a whole bunch of silent mistakes and issues that you won't have enough data to fix reliably until you switch to explicit offsets in all timestamp evaluations.
You're describing a world that doesn't exist from my experience writing booking systems.
Getting time zone conversions right all the way through the stack is far from trivial, which is why I prefer to do it in one place and keep the rest of the system out of it.
> If your code is protected from untrusted user data and the internet, Python 2 is actually a really nice language that doesn't constantly force rewrites.
If Python 2 is acceptable for your use case, then you could stay on an old version of Python 3 just fine as well.
I think the point was making sure that code won’t break in the future. If you tell someone „use python 2 to run my script“, you know it’s going to work basically forever because the latest python 2 won’t be changed. That’s not true for python 3. I still think it’s a bad argument, but that’s what I understood the idea as.
That argument still seems inconsistent to me, since saying "use python 2, pin your dependences and never upgrade python so your script runs forever" is the same as "use python 3.12, pin your dependences and never upgrade python so your script runs forever".
Although 3.1 also meets that criteria. And even with python 2, the dependencies could still update. The main thing is that it's the not-updating that will make your code run forever (on any system, language, version), not the fact that it's python 2.
No you can't. For example I use a script to compress scanned PDFs by combining individually processed JBIG2 images and that script hasn't been updated for more than a decade: https://github.com/agl/jbig2enc/blob/master/pdf.py It works and generates perfectly good PDFs. No it doesn't work with Python 3 because it mixes bytes and strings copiously. I could spend half an hour upgrading it to work with Python 3 but there's no reason to.
Don't forget the whole reason why Python 3 exists is because it broke compatibility with Python 2. Plenty of old unmaintained scripts were forever stuck in Python 2. Not to mention an old version of Python 3 actually performs worse than Python 2.
> I could spend half an hour upgrading it to work with Python 3 but there's no reason to.
How about empowering people other than yourself to understand how the code works, rather than relying on them to decipher the precise way in which you "mixed bytes and strings copiously"?
What if someone else did it for you? Would you reject the PR on principle?
The code was not written by me. I merely found this code useful.
If the author, Adam, or someone else upgraded it I would be happy using it with Python 3. But the code works as is. I'm also happy using it with Python 2.
Nothing is untrusted. I trust my own scanner. It's just that it produces files that are too large. And when it is told to reduce file size, it reduces resolution instead of using good compression.
Oh, you want to know the naive UTC datetime in Python, to interface with something like PostgreSQL that recommends naive times? Back in the old days, a simple datetime.datetime.utcnow(). Now days, you need something like: