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 tracker <rep...@bugs.python.org> <http://bugs.python.org/issue2736> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
