Velko Ivanov viva...@ivanov-nest.com added the comment:
I'm very disappointed by the outcome of this discussion.
You are committing the biggest sin of modern times - instead of promoting the
obtaining and usage of knowledge to solve things, you place restrictions to
force the dumbheads into not doing mistakes. The big problem with that is that
you can never foresee all usecases and all possible mistakes, thus you will
always be sorrily bitten by dumbheads. What does that make of you?
Let me present you a situation - I have a system that passes data via JSON,
datetime object is not JSON serializable. For few other reasons, like the epoch
and float secs since epoch being defacto standard, and the fact that I
absolutely make sure at-the-source that my timestamps are UTC and lack zone
awareness, and the fact that I'm not going to display those, but only use them
for comparison, and that I'm not going to do historical things and calculations
and I don't actually need nanosecond precision, just a tenth of the second, and
I'm fine with always using the '' and '', not the '==', and the fact that 90%
of the cases when use datetimes I have exactly the same requirements and it has
always been working fine for me - I choose the lightweight float representation
at the one side of the system.
In the SQL DB I use tz unaware timestamps, not floats and my DB access layer
returns datetime objects and I prefer them at this end of the system. So I only
need to serialize the datetime object. Well, as a matter of fact I have a JSON
object serialization already in place for some of my objects, but I do not need
that for tz unaware datetimes.
So I look for a method that makes a float from a datetime, which I'm used to in
PHP, Java, .NET, C, SQL and you name it. And I'm 2 hours into reading about
time, datetime and calendar modules and I still haven't even invented the
obscure time.mktime(dt.timetuple())+dt.microseconds*1e-6 . And to even think
that this creates a timetuple internally ? I hate it instantly and I dismiss
the possibility that the API could be so wrong and I keep searching - on the
internets - which brings me here where all my illusions are finally buried
into the dust.
2 Hours for something, that only needs a few warning lines in the docs?
Ok, the ultimately right thing is to actually serialize the datetime object and
rework my other end of the system to use dt instead of float .. maybe .. but
not now - now I'm only testing an idea for something completely different and I
only need faithful and dutiful Python to give me a float from datetime so I can
check something.
I love Python for being simple, logical and consistent and for giving me the
tools and not telling me what to do with them.
Not today ... Today Python goes - 'Here is your hammer, but you can not use it
to hit straight down. If you hit straight down, and you are using a forge, and
you miss your object and hit the forge instead, the hammer could ricochet and
hit you back on the forehead, so you can't use it that way. As a matter of
fact, there is a gyroscopic sensor embedded in the handle of the hammer and if
you try to hit with an angle that is close to 90 degrees, it will detach the
head of the hammer from the handle and prevent you from eventually endangering
yourself' and I'm like 'WTF??! I'm nailing a nail into a wooden plank!'
Now I'm going to use the obscure one liner and hate it, because it is simply
wrong and only someone that doesn't care of implementation detail might think
it equal to a proper solution.
The worst thing is, that I learned today, that if I ever need operations with
tz aware dates and time intervals in Python, I should actually send an SQL
query for that, because my DB has a clean, simple and COMPLETE date/time API
that works seamlessly. Yours is a jungle and I see you being asked to include a
ready made patch to output a float from a dt, to which you respond by adding a
locatime() method 2 years later.
You seriously think, that #9527 solves this? I don't even see a connection.
With #9527 in the python library I would be exactly what I am now - overly
frustrated and with the exactly same amount of time completely lost into
studying a bunch of tools only to realize that I should avoid using them at all
costs.
I'm sorry if I offend somebody by posting this emotional message, I just try to
give you another point of view - don't put restrictions and hide the reasoning.
Instead, support the thing that is widespread and advise that in certain
conditions there are better things to do. And if it doesn't work for some edge
cases, or even for half the cases - place a well elaborated warning. Then if
programmers still make the mistake - well, let them learn by it. 'Cause that's
the way people learn .. they make mistakes. By preventing them from making the
mistake, you actually rob them of learning.
--
nosy: +vivanov
___
Python
