Re: YADTR (Yet Another DateTime Rant)
On Thu, 27 Mar 2014 20:29:17 -0400, Roy Smith wrote: In article 5334b747$0$29994$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Thu, 27 Mar 2014 08:52:24 -0400, Roy Smith wrote: In article mailman.8613.1395917059.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: It's not equally braindead, it follows a simple and logical rule: Only the day portion is negative. Simple and logical, yes. But also entirely braindead. Do you think it is braindead for __str__ to return something which follows the internal representation of the object? Yes. The whole idea of OOD is to decouple internal representation from external behavior. The *whole* idea? You don't think that encapsulation and inheritance might also be involved? *wink* Besides, there's a difference between internal _representation_ and internal _implementation_. I don't always choose my words carefully, but this was one of those times :-) A timedelta object *represents* a delta as (days + seconds + microseconds). That is part of the interface, not implementation. How it is actually implemented is irrelevant. (If I were to take a wild guess, I'd predict that timedeltas record the total number of seconds.) Give ma a real-life situation where you would want such behavior. Easy -- I'm debugging timedelta routines, and I want to easily see that the timedeltas calculated match what I expect them to be when I print them. The quickest, easiest and simplest way is for str(timedelta) to follow the internal representation. That's what __repr__() is for. Actually, __repr__ should, if practical, match the constructor for the object: py import datetime py t = datetime.timedelta(2, 3) py eval(repr(t)) == t True Oh look, that's exactly what the docs say: String representations of timedelta objects are normalized similarly to their internal representation. This leads to somewhat unusual results for negative timedeltas. Yes, I know that's what the docs say. That's why it's not an implementation bug. It's a design bug :-) I don't think it is. Given a timedelta object with D days, S seconds and M microseconds, I think that it is a very useful property if the string also says it has D days, S seconds and M microseconds. Would you not agree? I think that this would be silly: str(timedelta(1, 0, 0)) = '0 day, 24:01:-5184000.0' even though it would be correct. So we can dismiss the idea that the str of a timedelta should be free to arbitrarily vary from the internal representation. I consider this to be a useful constraint on timedelta's internal representation (not implementation): the seconds and microseconds should be normalised to the half-open intervals, 0 to 86400 for seconds and 0 to 100 for microseconds. Given that constraint, and the previous constraint that strings should show the same number of days etc., and we have the current behaviour. Both constraints are reasonable. You have to weaken one, or the other, in order to get the result you want. That's not necessarily unreasonable, but neither is it a given. Python-Dev is not normally braindead, so at least given them the benefit of the doubt that *maybe* there's some good reason we haven't thought of. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
In article 533558fa$0$29994$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Yes. The whole idea of OOD is to decouple internal representation from external behavior. The *whole* idea? You don't think that encapsulation and inheritance might also be involved? *wink* I'm not sure how decoupling internal representation from external behavior is substantially different from encapsulation. And, no, I don't think inheritance is a fundamental characteristic of OOD, nudge nudge. -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
In article mailman.8667.1396012782.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Sat, Mar 29, 2014 at 12:10 AM, Marko Rauhamaa ma...@pacujo.net wrote: If encapsulation exists outside OO and inheritance is not key to it, what is OO then, a marketing term? Yep, OO is a marketing term. So's programming - after all, it's just flipping bits in memory... we only pretend it means anything. Do I really exist, or do I just think I do? ChrisA The real question is, what does this print: c1 = ChrisA() c2 = ChrisA() print c1 == c2 print c2 is c2 -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Sat, Mar 29, 2014 at 12:22 AM, Roy Smith r...@panix.com wrote: In article mailman.8667.1396012782.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Sat, Mar 29, 2014 at 12:10 AM, Marko Rauhamaa ma...@pacujo.net wrote: If encapsulation exists outside OO and inheritance is not key to it, what is OO then, a marketing term? Yep, OO is a marketing term. So's programming - after all, it's just flipping bits in memory... we only pretend it means anything. Do I really exist, or do I just think I do? ChrisA The real question is, what does this print: c1 = ChrisA() c2 = ChrisA() print c1 == c2 print c2 is c2 And if you could answer that, you would know whether my mother was right when, in exasperation, she would say Your design follows the singleton principle!. Okay, so she actually was more likely to say You are one of a kind!, but it comes to the same thing... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
In article 871txmwjt4@elektro.pacujo.net, Marko Rauhamaa ma...@pacujo.net wrote: what is OO then, a marketing term? Sometimes, I think it must be :-) (It's a different thing, then, that encapsulation and inheritance are mutually exclusive principles.) There're certainly not mutually exclusive. Mutually exclusive means if you have one, you can't have the other. I think the phrase you're looking for is orthogonal concepts. You can have either, or both, or neither, and the existence of one doesn't imply anything about the existence of the other. -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Friday, March 28, 2014 6:52:15 PM UTC+5:30, Roy Smith wrote: Chris Angelico wrote: On Sat, Mar 29, 2014 at 12:10 AM, Marko Rauhamaa wrote: If encapsulation exists outside OO and inheritance is not key to it, what is OO then, a marketing term? Yep, OO is a marketing term. So's programming - after all, it's just flipping bits in memory... we only pretend it means anything. Do I really exist, or do I just think I do? ChrisA The real question is, what does this print: c1 = ChrisA() c2 = ChrisA() print c1 == c2 print c2 is c2 OO is of course a marketing term Unicode OTOH is the real cure for all diseases Proof by example: Replace the last with print c2 ≡ c2 or even better print c2 ≣ c2 No confusion any more... See? We all know now who (what?) Chris is! -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Sat, Mar 29, 2014 at 1:35 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: It's difficult to pin-point exactly what characteristics of OOP are fundamental, but inheritance is surely one of them. I've always understood OOP to be all about binding code and data together (methods as part of an object, rather than functions operating on data) - ie polymorphism, such that you say do this and the object knows how its do this should be done. That's at least as important as inheritance IMO. But yes, it is very hard to pin it down. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
Roy Smith r...@panix.com: There're certainly not mutually exclusive. Mutually exclusive means if you have one, you can't have the other. Correct. The classic inheritance diamond: class A(B, C): def add_bean(self): ??? # how to implement class B(D): pass class C(D): pass class D: def __init__(self): self.beans = 0 def add_bean(self): self.beans += 1 def bean_count(self): return self.beans cannot be dealt with without A addressing the common base class D. And once it deals with it, A can be broken by reimplementing C without inheriting it from D: class C: def __init__(self): self.beans = def add_bean(self): self.beans += o def bean_count(self): return len(self.beans) thus violating encapsulation. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
Roy Smith r...@panix.com: I'm not sure how decoupling internal representation from external behavior is substantially different from encapsulation. Yes, that's encapsulation. The idea of encapsulation is older than OO. And, no, I don't think inheritance is a fundamental characteristic of OOD, nudge nudge. Inheritance was there with Simula so I think it's high up there with OO. If encapsulation exists outside OO and inheritance is not key to it, what is OO then, a marketing term? (It's a different thing, then, that encapsulation and inheritance are mutually exclusive principles.) Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Sat, Mar 29, 2014 at 12:10 AM, Marko Rauhamaa ma...@pacujo.net wrote: If encapsulation exists outside OO and inheritance is not key to it, what is OO then, a marketing term? Yep, OO is a marketing term. So's programming - after all, it's just flipping bits in memory... we only pretend it means anything. Do I really exist, or do I just think I do? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Fri, 28 Mar 2014 08:30:11 -0400, Roy Smith wrote: In article 533558fa$0$29994$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Yes. The whole idea of OOD is to decouple internal representation from external behavior. The *whole* idea? You don't think that encapsulation and inheritance might also be involved? *wink* I'm not sure how decoupling internal representation from external behavior is substantially different from encapsulation. They are mostly unrelated. In the first, you're talking about information hiding. The second, encapsulation, relates to the bundling of code and data, optionally in such a way as to restrict or control access to some or all of the encapsulated data. Encapsulation can be used as a mechanism for information hiding, but need not be. https://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29 And, no, I don't think inheritance is a fundamental characteristic of OOD, nudge nudge. That's not representative of what most people, and specifically most computer scientists, consider fundamental to OOP. https://en.wikipedia.org/wiki/Object-oriented_programming#Fundamental_features_and_concepts It's difficult to pin-point exactly what characteristics of OOP are fundamental, but inheritance is surely one of them. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On 27/03/2014 01:38, Roy Smith wrote: In article mailman.8597.1395883727.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Thu, Mar 27, 2014 at 11:16 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: If an event happened 30 hours ago, it is correct to say that it occurred 18 hours after 2 days ago, but who talks that way? That response demonstrates real genius. Rue the datetime? Who talks like that? I had a dangling pointer error, and blew my stack to half past last wednesday IIRC the Germans (possibly amongst others) would say that as half to last thursday, or is that thurstag? :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On 26.03.2014 10:53, Jean-Michel Pichavant wrote: Note : I don't see what's wrong in your example, however I have the feeling the term stupiditie is a little bit strong ;) The problem is that for a given timedelta t with t 0 it is intuitive to think that its string representation str(t) would follow the rule - + str(t) == str(-t) But it doesn't. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. I hereby inform you that I - probably by accident received your very confidential and privileged message! All hardware has already been thrown into the incinerator, is that good enough for you? Or do I have to fulfill some ISO-9001 certified privileged mail destruction procedure? Please advise on how I shall continue my life. Cheers, Johannes IMPORTANT NOTICE: If you write mails to newsgroups with a ridiculous confidentiality footer, you are obliged under section 14.9a of the Imbecile Act to take a blunt object of no less than 12 kg weight and hit yourself repeatedly in the head until the email footer disappears. Failure to comply might lead to criminal prosecution and/or permanent constipation! Thank you. -- Wo hattest Du das Beben nochmal GENAU vorhergesagt? Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa hidbv3$om2$1...@speranza.aioe.org -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On 27.03.2014 01:16, Steven D'Aprano wrote: py divmod(30, 24) (1, 6) That makes perfect intuitive sense: 30 hours is 1 day with 6 hours remaining. In human-speak, we'll say that regardless of whether the timedelta is positive or negative: we'll say 1 day and 6 hours from now or 1 day and 6 hours ago. But when we specify the sign: py divmod(-30, 24) (-2, 18) If an event happened 30 hours ago, it is correct to say that it occurred 18 hours after 2 days ago, but who talks that way? Well, no matter how timedeltas internal representation is and if they use modular division or (they probably do, I agree) this shouldn't affect the display at all. Internally they can use any arbitrary representation, but for the external representation I think a very sane requirement should be that for a given timedelta t with t 0 it is its string representation str(t) would satisfy: - + str(t) == str(-t) Besides, there's an infinite amount of (braindead) timedelta string representations. For your -30 hours, it is perfectly legal to say 123 days, -2982 hours Yet Python doesn't (but chooses an equally braindead representation). Where can I enter a PIP that proposes that all timedelta strings are fixed at 123 days (for positive, non-prime amount of seconds) and fixed at -234 days (for all negative or positive prime amount of seconds)? Cheers, Johannes -- Wo hattest Du das Beben nochmal GENAU vorhergesagt? Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa hidbv3$om2$1...@speranza.aioe.org -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Thu, Mar 27, 2014 at 9:22 PM, Johannes Bauer dfnsonfsdu...@gmx.de wrote: Besides, there's an infinite amount of (braindead) timedelta string representations. For your -30 hours, it is perfectly legal to say 123 days, -2982 hours Yet Python doesn't (but chooses an equally braindead representation). It's not equally braindead, it follows a simple and logical rule: Only the day portion is negative. That might not be perfectly suited to all situations, but it does mean that adding and subtracting whole days will never change the representation of the time. That's a reasonable promise. What you propose is completely arbitrary, and yes it WOULD be braindead to have str() return that (although of course this should be accepted as input). Where can I enter a PIP that proposes that all timedelta strings are fixed at 123 days (for positive, non-prime amount of seconds) and fixed at -234 days (for all negative or positive prime amount of seconds)? Doesn't need a PEP. Just subclass it or monkey-patch it and use it as you will. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On 27.03.2014 11:44, Chris Angelico wrote: On Thu, Mar 27, 2014 at 9:22 PM, Johannes Bauer dfnsonfsdu...@gmx.de wrote: Besides, there's an infinite amount of (braindead) timedelta string representations. For your -30 hours, it is perfectly legal to say 123 days, -2982 hours Yet Python doesn't (but chooses an equally braindead representation). It's not equally braindead, it follows a simple and logical rule: Only the day portion is negative. That might not be perfectly suited to all situations, but it does mean that adding and subtracting whole days will never change the representation of the time. That's a reasonable promise. Why would the stability of the *string* output of the time representation be of any interest whatsoever? Do you have any even halfways reasonable usecase for that? What you propose is completely arbitrary, No. What I propose is that for t 0 this holds: - + str(t) == str(-t) Which is far from arbitrary. It follows natural rules of inverting something (-abs(x) == -x), and it yields a (truly) human-readable form of showing a timedelta. Please don't mix this up with the very apparent braindead proposal of mine. In case you didn't notice, this was irony at work. The word braindead I chose to describe the format should have tipped you off to that. Where can I enter a PIP that proposes that all timedelta strings are fixed at 123 days (for positive, non-prime amount of seconds) and fixed at -234 days (for all negative or positive prime amount of seconds)? Doesn't need a PEP. Just subclass it or monkey-patch it and use it as you will. :) Nonono, you misunderstand: I want everyone to suffer under the braindead representation, just as it is now! Cheers, Johannes -- Wo hattest Du das Beben nochmal GENAU vorhergesagt? Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa hidbv3$om2$1...@speranza.aioe.org -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On 27.03.2014 11:44, Chris Angelico wrote: It's not equally braindead, it follows a simple and logical rule: Only the day portion is negative. The more I think about it, the sillier this rule seems to me. A timedelta is a *whole* object. Either the whole delta is negative or it is not. It doesn't make sense to split it up in two parts and arbitrarily define one to be always nonnegative and the other to have no restrictions. The only locical reasoning behind this could be to argue that -2 days makes more sense than -15 minutes. Which it doesn't. Worse: Negating a timedelta (which I would argue is a fairly common operation) makes the whole thing unstable representation-wise: str(datetime.timedelta(2, 30)) '2 days, 0:00:30' str(-datetime.timedelta(2, 30)) '-3 days, 23:59:30' And it makes it extremely error-prone to the reader: str(datetime.timedelta(0, -1)) '-1 day, 23:59:59' This looks MUCH more like almost two days ago than '-00:00:01' does. In any case, the str() function is *only* about the representation that can be read by humans. Therefore its highest priority should be to output something that can, in fact, be easily parsed by humans. The current format is nothing of the sort. Cheers, Johannes -- Wo hattest Du das Beben nochmal GENAU vorhergesagt? Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa hidbv3$om2$1...@speranza.aioe.org -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Thu, Mar 27, 2014 at 10:05 PM, Johannes Bauer dfnsonfsdu...@gmx.de wrote: On 27.03.2014 11:44, Chris Angelico wrote: On Thu, Mar 27, 2014 at 9:22 PM, Johannes Bauer dfnsonfsdu...@gmx.de wrote: Besides, there's an infinite amount of (braindead) timedelta string representations. For your -30 hours, it is perfectly legal to say 123 days, -2982 hours Yet Python doesn't (but chooses an equally braindead representation). It's not equally braindead, it follows a simple and logical rule: Only the day portion is negative. That might not be perfectly suited to all situations, but it does mean that adding and subtracting whole days will never change the representation of the time. That's a reasonable promise. Why would the stability of the *string* output of the time representation be of any interest whatsoever? Do you have any even halfways reasonable usecase for that? What you propose is completely arbitrary, No. What I propose is that for t 0 this holds: - + str(t) == str(-t) Which is far from arbitrary. When you said equally braindead, I took that as indicating that the current representation is as braindead as 123 days, -2982 hours. My point is that it's not as arbitrary as that. Your real proposal, if you like, is arguably better; but I'm just saying that the current one isn't arbitrary. It follows natural rules of inverting something (-abs(x) == -x), and it yields a (truly) human-readable form of showing a timedelta. Please don't mix this up with the very apparent braindead proposal of mine. In case you didn't notice, this was irony at work. The word braindead I chose to describe the format should have tipped you off to that. Yes, I knew that that was irony. I was taking argument with your declaration that the current form is just as bad. Taking it to a different type: The repr() of a string tries to be short, where possible, by using either single or double quotes, but won't use a raw representation, nor triple-quoted: ' \' ' ' \ ' ' ' \\'\\'\\'\\' ' ' \'\'\'\' ' \\'\\'\\'\\' ' \'\'\'\' ' ''' ''' ' \'\'\'\' ' r' \\ ' ' ' You could argue that representing a string as raw or triple-quoted would be more correct, and yet the current repr is not arbitrary. The current form is not actively bad, even if it would be possible to find something better. Where can I enter a PIP that proposes that all timedelta strings are fixed at 123 days (for positive, non-prime amount of seconds) and fixed at -234 days (for all negative or positive prime amount of seconds)? Doesn't need a PEP. Just subclass it or monkey-patch it and use it as you will. :) Nonono, you misunderstand: I want everyone to suffer under the braindead representation, just as it is now! Oh, absolutely! In that case, just slip a patch into the next point release; people won't mind that changing in 3.4.1! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Thu, Mar 27, 2014 at 10:25 PM, Johannes Bauer dfnsonfsdu...@gmx.de wrote: And it makes it extremely error-prone to the reader: str(datetime.timedelta(0, -1)) '-1 day, 23:59:59' This looks MUCH more like almost two days ago than '-00:00:01' does. It's easy when the timedelta is -1 day. Is it as clear when it's further negative? In any case... what I'd suggest would be opening a tracker issue, or discussing this on python-ideas, and seeing what core devs think of the matter. I think that, on balance, it's probably better to show the whole thing with the same sign; but should it be: str(datetime.timedelta(-1, -1)) '-1 day, 00:00:01' or should the hyphen be repeated: str(datetime.timedelta(-1, -1)) '-1 day, -00:00:01' ? How does it read in a larger expression? All this bikeshedding, and more, available gratis on python-ideas. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
I took a moment to scan the datetime documentation. The behavior of str() on timedelta objects is very consistent, and matches the internal representation. From the docs: str(t) Returns a string in the form [D day[s], ][H]H:MM:SS[.UU], where D is negative for negative t. (5) Note (5) reads: String representations of timedelta objects are normalized similarly to their internal representation. This leads to somewhat unusual results for negative timedeltas. Feel free to submit a patch to improve str(t), where t is negative, though as Chris suggested, hashing this out on python-ideas would be a good idea. I suggest you start with some concrete examples. There are, as I see it, two common cases where t is negative: -1 day t 0 and t = -1 day Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Thu, Mar 27, 2014 at 10:56 PM, Skip Montanaro s...@pobox.com wrote: There are, as I see it, two common cases where t is negative: -1 day t 0 and t = -1 day There are two types of negative numbers: Those closer to zero than -1, and those not closer to zero than -1. Yeah, I think those are the most common cases. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Thu, Mar 27, 2014 at 9:22 PM, Johannes Bauer dfnsonfsdu...@gmx.de wrote: Besides, there's an infinite amount of (braindead) timedelta string representations. For your -30 hours, it is perfectly legal to say 123 days, -2982 hours Yet Python doesn't (but chooses an equally braindead representation). In article mailman.8613.1395917059.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: It's not equally braindead, it follows a simple and logical rule: Only the day portion is negative. Simple and logical, yes. But also entirely braindead. That might not be perfectly suited to all situations Give ma a real-life situation where you would want such behavior. What you propose is completely arbitrary, and yes it WOULD be braindead to have str() return that Chris, I believe you need to have your sarcasm detection circuitry recalibrated :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
There are, as I see it, two common cases where t is negative: -1 day t 0 and t = -1 day There are two types of negative numbers: Those closer to zero than -1, and those not closer to zero than -1. Yeah, I think those are the most common cases. :) Sorry I wasn't clear. I see two cases w.r.t. *display*, those where you need to display the number of days back (possibly accounting for even larger time intervals to make it more human readable), those where you don't. Yes, as you observed, they completely cover the negative timedelta space with two non-overlapping intervals. Roy's original rant was about how a negative timedelta was stringified, when what he seemed to care about was mostly the time interval between now and the previous sunset (which will be less than a day, unless your day length is advancing -- between the winter and summer solstices -- and you compute that interval a few seconds before sunset). The common how long ago was sunset? (|delta| 1 day) case is handled just fine by my little negate-the-timedelta hack, e.g.: -%s % (-datetime.timedelta(hours=-17, minutes=-12, seconds=-25.234)) '-17:12:25.234000' Negative timedeltas with a magnitude of one day or more require something else, perhaps like the ISO8601 duration stuff (which I personally find distasteful, but that might be the best you can do in the absence of an anchor datetime). Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Fri, Mar 28, 2014 at 1:12 AM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: I don't recall specifics, but I do remember multiple times where I was working with a structure that consisted of a whole part and a fracture part where I found it useful to have the fracture part always positive and displayed as such. One has already been shared in this thread: Logarithms, where the part before the decimal is the scale and the part after the decimal is the mantissa. Makes very good sense to negate the first without changing the second. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
Skip Montanaro s...@pobox.com: Feel free to submit a patch to improve str(t), where t is negative, The cat's out of the bag already, isn't it? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On 27-03-14 13:52, Roy Smith wrote: On Thu, Mar 27, 2014 at 9:22 PM, Johannes Bauer dfnsonfsdu...@gmx.de wrote: Besides, there's an infinite amount of (braindead) timedelta string representations. For your -30 hours, it is perfectly legal to say 123 days, -2982 hours Yet Python doesn't (but chooses an equally braindead representation). In article mailman.8613.1395917059.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: It's not equally braindead, it follows a simple and logical rule: Only the day portion is negative. Simple and logical, yes. But also entirely braindead. That you don't have a use for it and don't like it doesn't make it brain dead. That might not be perfectly suited to all situations Give ma a real-life situation where you would want such behavior. What good would that do? The fact that someone else could give a real-life situation where they wanted that, wouldn't mean that you would recognize it as a situation where you wanted it, and so you could still call it brain dead. I don't recall specifics, but I do remember multiple times where I was working with a structure that consisted of a whole part and a fracture part where I found it useful to have the fracture part always positive and displayed as such. Your background is obviously different and you don't like it. Fine, that doesn't make it brain dead. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On 3/27/2014 7:42 AM, Chris Angelico wrote: In any case... what I'd suggest would be opening a tracker issue, or discussing this on python-ideas, and seeing what core devs think of the matter. I think that, on balance, it's probably better to show the whole thing with the same sign; but should it be: Before doing so, I suggest looking for the design discussion either on the tracker or in python-ideas or py-dev lists. str(datetime.timedelta(-1, -1)) '-1 day, 00:00:01' or should the hyphen be repeated: str(datetime.timedelta(-1, -1)) '-1 day, -00:00:01' '-(1 day, 00:00:01)' should be unambiguous. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Thu, 27 Mar 2014 08:52:24 -0400, Roy Smith wrote: In article mailman.8613.1395917059.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: It's not equally braindead, it follows a simple and logical rule: Only the day portion is negative. Simple and logical, yes. But also entirely braindead. Do you think it is braindead for __str__ to return something which follows the internal representation of the object? Note that I'm not asking if that is the best choice for every object, or even the best choice for any object. You've made an extremely strong claim, by calling something braindead you're essentially arguing that this is an *utterly irredeemable choice whatsoever* with absolutely no redeeming features. Hyperbole is fun, that's why we do it. It allows us to build up a nice feeling of righteous indignation over something utterly outrageous and indefensible, without having to worry about inconvenient distractions like other points of view :-) That might not be perfectly suited to all situations Give ma a real-life situation where you would want such behavior. Easy -- I'm debugging timedelta routines, and I want to easily see that the timedeltas calculated match what I expect them to be when I print them. The quickest, easiest and simplest way is for str(timedelta) to follow the internal representation. Oh look, that's exactly what the docs say: String representations of timedelta objects are normalized similarly to their internal representation. This leads to somewhat unusual results for negative timedeltas. as Skip has already pointed out. Is this the *best* choice for a timedelta? Probably not. But it's a simple, logical, *reasonable* choice. It only fails the reasonable test if you insist that timedelta objects *must* match the time-keeping conventions of native English speakers, and any other convention is unspeakable. For all we know, maybe (say) Koreans or Egyptians or Gaelic Scots do say something like It was a day ago, less four hours meaning twenty hours ago. Stranger things happen in natural language, and we ought to be cautious about insisting that English conventions are universal. (Given Johannes Bauer's reaction, we can be fairly certain that German speakers follow a similar convention to English speakers. Which shouldn't be terribly surprising, since English is a Germanic language.) A few seconds searching the bug tracker shows that this is not, in fact, a bug in timedelta but probably a deliberate feature: http://bugs.python.org/issue9430 This one is also relevant: http://bugs.python.org/issue1569623 Alas, the discussion appears to have been on #python-dev, which (probably) means it is not archived anywhere. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On 03/27/2014 02:10 PM, Terry Reedy wrote: On 3/27/2014 7:42 AM, Chris Angelico wrote: In any case... what I'd suggest would be opening a tracker issue, or discussing this on python-ideas, and seeing what core devs think of the matter. I think that, on balance, it's probably better to show the whole thing with the same sign; but should it be: Before doing so, I suggest looking for the design discussion either on the tracker or in python-ideas or py-dev lists. -- str(datetime.timedelta(-1, -1)) '-1 day, 00:00:01' or should the hyphen be repeated: -- str(datetime.timedelta(-1, -1)) '-1 day, -00:00:01' '-(1 day, 00:00:01)' should be unambiguous. Or change the comma to an and: '-1 day and 00:00:01' -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
In article 5334b747$0$29994$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Thu, 27 Mar 2014 08:52:24 -0400, Roy Smith wrote: In article mailman.8613.1395917059.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: It's not equally braindead, it follows a simple and logical rule: Only the day portion is negative. Simple and logical, yes. But also entirely braindead. Do you think it is braindead for __str__ to return something which follows the internal representation of the object? Yes. The whole idea of OOD is to decouple internal representation from external behavior. Give ma a real-life situation where you would want such behavior. Easy -- I'm debugging timedelta routines, and I want to easily see that the timedeltas calculated match what I expect them to be when I print them. The quickest, easiest and simplest way is for str(timedelta) to follow the internal representation. That's what __repr__() is for. Oh look, that's exactly what the docs say: String representations of timedelta objects are normalized similarly to their internal representation. This leads to somewhat unusual results for negative timedeltas. Yes, I know that's what the docs say. That's why it's not an implementation bug. It's a design bug :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
Roy Smith r...@panix.com writes: In article 5334b747$0$29994$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Thu, 27 Mar 2014 08:52:24 -0400, Roy Smith wrote: Give ma a real-life situation where you would want such behavior [the ‘datetime.timedelta.__str__’ method returning a string showing some portions negative and others positive]. Easy -- I'm debugging timedelta routines, and I want to easily see that the timedeltas calculated match what I expect them to be when I print them. The quickest, easiest and simplest way is for str(timedelta) to follow the internal representation. That's what __repr__() is for. Indeed, that is why Python's data model defines separate ‘__str__’ and ‘__repr__’ methods. object.__repr__(self) […] If at all possible, this should look like a valid Python expression that could be used to recreate an object with the same value (given an appropriate environment). If this is not possible, a string of the form ...some useful description... should be returned. URL:http://docs.python.org/3/reference/datamodel.html#object.__repr__ object.__str__(self) […] compute the “informal” or nicely printable string representation of an object. […] a more convenient or concise representation can be used. URL:http://docs.python.org/3/reference/datamodel.html#object.__str__ If you're a programmer wanting to know about the internal representation of an object, call its ‘__repr__’ method (by calling ‘repr(foo)’). If you're wanting to see a string representation that follows the *semantics* of the object, call its ‘__str__’ method (by calling ‘str(foo)’). If the ‘__str__’ method follows the internal representation at the expense of the user's conceptual model, that's terrible (which I think is what Roy means by “braindead”). I wouldn't go as far as that insult, because it could be mere omission: The default implementation [of ‘__str__’] defined by the built-in type object calls object.__repr__(). So, where ‘str(foo)’ is returning an unhelpful representation that follows the implementation, it could simply be that there is no ‘__str__’ defined for that type. Oh look, that's exactly what the docs say: String representations of timedelta objects are normalized similarly to their internal representation. This leads to somewhat unusual results for negative timedeltas. Yes, I know that's what the docs say. That's why it's not an implementation bug. It's a design bug :-) One which to some extent violates the defined data model for Python objects, and hence should be fixed. -- \ “I don't know half of you half as well as I should like, and I | `\ like less than half of you half as well as you deserve.” —Bilbo | _o__) Baggins | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On 3/27/2014 5:10 PM, Terry Reedy wrote: On 3/27/2014 7:42 AM, Chris Angelico wrote: In any case... what I'd suggest would be opening a tracker issue, or discussing this on python-ideas, and seeing what core devs think of the matter. I think that, on balance, it's probably better to show the whole thing with the same sign; but should it be: Before doing so, I suggest looking for the design discussion either on the tracker or in python-ideas or py-dev lists. And skip the troll word 'braindead'. Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
In article mailman.8647.1395971209.18130.python-l...@python.org, Terry Reedy tjre...@udel.edu wrote: On 3/27/2014 5:10 PM, Terry Reedy wrote: On 3/27/2014 7:42 AM, Chris Angelico wrote: In any case... what I'd suggest would be opening a tracker issue, or discussing this on python-ideas, and seeing what core devs think of the matter. I think that, on balance, it's probably better to show the whole thing with the same sign; but should it be: Before doing so, I suggest looking for the design discussion either on the tracker or in python-ideas or py-dev lists. And skip the troll word 'braindead'. Terry Jan Reedy I apologize for my poor choice of vocabulary. -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On 3/27/2014 9:59 PM, Roy Smith wrote: In article mailman.8647.1395971209.18130.python-l...@python.org, Terry Reedy tjre...@udel.edu wrote: On 3/27/2014 5:10 PM, Terry Reedy wrote: On 3/27/2014 7:42 AM, Chris Angelico wrote: In any case... what I'd suggest would be opening a tracker issue, or discussing this on python-ideas, and seeing what core devs think of the matter. I think that, on balance, it's probably better to show the whole thing with the same sign; but should it be: Before doing so, I suggest looking for the design discussion either on the tracker or in python-ideas or py-dev lists. And skip the troll word 'braindead'. I apologize for my poor choice of vocabulary. I actually meant if you post on the tracker or python-ideas. There is a little more leeway here. But as you maybe noticed. even here a trollish word can divert discussion from you main point. Back to your main point: the current output looks strange to me also. But I did not follow the datetime development discussion. I do know that the people responsible are not normally braindead ;-). -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Fri, Mar 28, 2014 at 1:24 PM, Terry Reedy tjre...@udel.edu wrote: I do know that the people responsible are not normally braindead ;-). Yeah, anyone who develops Python is clearly abnormally braindead... *dives for cover* ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On 26/03/2014 01:19, Ethan Furman wrote: On 03/25/2014 05:58 PM, Roy Smith wrote: One of my roles on this newsgroup is to periodically whine about stupidities in the Python datetime module. This is one of those times. I have some code which computes how long ago the sun set. Being a nice pythonista, I'm using a timedelta to represent this value. It would be difficult to imagine a less useful default way to print a timedelta: previous sunset: -1 day, 22:25:26.295993 The idea of str() is that it's supposed to return a human-friendly representation of a value. Humans do not say things like, The sun set 1 day ago plus 22 hours and 25 minutes. I'm not sure whether to admire you for your stick-to-it-iveness, or pity you for the plight you are in. Either the first or second time I hit a datetime WTF moment I wrote my own wrapper classes. dateutils for me. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
It's not clear to me what the correct str should be. I think the desired format changes depending on the relative magnitude of the timedelta object. For small values (less than a day), I agree, the behavior is, well, odd. You can get around that easily enough: d = datetime.timedelta(seconds=-2) str(d) '-1 day, 23:59:58' -%s % -d '-0:00:02' The problem gets more challenging once you get into magnitudes one day: e = datetime.timedelta(days=-4, seconds=3605) e datetime.timedelta(-4, 3605) print e -4 days, 1:00:05 Hmmm... It's printing just what we said, negative four days, positive one hour, five minutes. Let's try the trick from above: print -e 3 days, 22:59:55 -%s % -e '-3 days, 22:59:55' Ehhh... not so much. The fundamental problem here is the scope of the minus sign. My trick assumes it applied to the entire string representation. It's clear that in the first case that it applies to the entire displayed value, as there are no spaces. In the second case, we know it only applies to the days, because it's spitting back exactly what I fed the constructor. So, that means the simple minus sign trick won't work in the third case. Complicating things are that timedelta objects are normalized internally so that the seconds field is always non-negative (explaining the weird -1 day, 23:59:58 string representation of the first case). I'm not sure there's a one-size-fits-all solution to this problem. For offsets of less than a day, I suppose you could argue that the string representation shouldn't include the -1 day bit. Beyond that, I think you kind of have to live with what it gives you. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On 26-03-14 01:58, Roy Smith wrote: One of my roles on this newsgroup is to periodically whine about stupidities in the Python datetime module. This is one of those times. I have some code which computes how long ago the sun set. Being a nice pythonista, I'm using a timedelta to represent this value. It would be difficult to imagine a less useful default way to print a timedelta: previous sunset: -1 day, 22:25:26.295993 The idea of str() is that it's supposed to return a human-friendly representation of a value. Humans do not say things like, The sun set 1 day ago plus 22 hours and 25 minutes. There is a difference between how people say things and what is useful. I remember when I was studying logarithms, a negative number like -5.73 was written down as ̅6.27 (with a bar only over the six). That notation had the advantage that the part after the decimal point stayed the same if you added or subtracted whole numbers. Even if that would change the sign. I can't give an honest estimation of how useful this notation is because I don't use the datetime module often enough. But I can imagine that those who wrote the module and I expect used it often found it a useful representation. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Thu, Mar 27, 2014 at 1:02 AM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: There is a difference between how people say things and what is useful. I remember when I was studying logarithms, a negative number like -5.73 was written down as ̅6.27 (with a bar only over the six). That notation had the advantage that the part after the decimal point stayed the same if you added or subtracted whole numbers. Even if that would change the sign. That's highly significant with logs, especially when you're working with base 10 logs. math.log10(1234) 3.091315159697223 math.log10(12340) 4.091315159697223 math.log10(123400) 5.091315159697223 math.log10(1234000) 6.091315159697223 math.log10(12.34) 1.0913151596972228 math.log10(1.234) 0.09131515969722287 math.log10(.1234) -0.9086848403027772 math.log10(.01234) -1.9086848403027772 By showing those last ones as 1̅.091... and 2̅.091..., you emphasize the floating-point nature of the data: everything after the decimal is the mantissa, and everything before the decimal is the exponent. I can't say for sure as I don't really use that, but I can imagine that there might be something similar with dates and times - it's three days ago at 2:51, not two days and 21:09 ago. Or maybe it's just print it out in a way that more closely matches the internal representation, to simplify debugging :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
Antoon Pardon antoon.par...@rece.vub.ac.be: On 26-03-14 01:58, Roy Smith wrote: previous sunset: -1 day, 22:25:26.295993 The idea of str() is that it's supposed to return a human-friendly representation of a value. Humans do not say things like, The sun set 1 day ago plus 22 hours and 25 minutes. There is a difference between how people say things and what is useful. There is a standard timedelta representation: URL: http://www.schemacentral.com/sc/xsd/t-xsd_duration.html URL: http://en.wikipedia.org/wiki/ISO_8601#Durations If timedelta() were created today, it really should use that one because it is the only standard one, even though few people would use that in a human interface. Thus: -P1DT22H25M26.295993S Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Wednesday, March 26, 2014 9:37:06 AM UTC-4, Skip Montanaro wrote: The problem gets more challenging once you get into magnitudes one day: e = datetime.timedelta(days=-4, seconds=3605) e datetime.timedelta(-4, 3605) print e -4 days, 1:00:05 Hmmm... It's printing just what we said, negative four days, positive one hour, five minutes. Let's try the trick from above: No, what you said was negative four days, positive 3605 seconds. Why does it make sense to normalize 3605 seconds to 1 hour, 5 seconds, but not extend that normalization to the days portion? Complicating things are that timedelta objects are normalized internally so that the seconds field is always non-negative The whole idea of datatypes is to hide the internal representation. If it's convenient on your platform, you can store timedeltas internally as fempto-years. That should not affect how it prints. -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Wed, Mar 26, 2014 at 10:04 AM, Roy Smith r...@panix.com wrote: No, what you said was negative four days, positive 3605 seconds. My apologies for not showing all my work, professor. I use datetime and timedelta objects all the time. I did the arithmetic to go from 3605 to one hour, five minutes in my head. The point of my post was that there is no obvious one best way to present negative timedeltas in a human readable form. In my usage it's not generally a big deal, as most of the time I want to display datetime objects. In your case, it's obviously a problem. If Tim thought that timedelta objects would be presented to users as a regular course of doing business, maybe he would have given them a strftime() method. I suggest you write a function to format it the way you want and be done with it. You might consider taking a crack at a strftime() (and strptime?) implementation for timedelta objects that uses the ISO 8601 notation and submit it as a patch for datetimemodule.c. Note though, that the ISO8601 representation isn't without its own flaws (which might explain why Tim avoided it BITD): * It doesn't appear to provide a way to represent fractions of a second (though perhaps all the fields can be fractional) * How many days are in a month or a year? (It has format codes for both. Writing a useful strptime is probably impossible.) * It has other ambiguities (M represents both months and minutes - what were they thinking?) Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Mar 26, 2014, at 11:39 AM, Skip Montanaro wrote: The point of my post was that there is no obvious one best way to present negative timedeltas in a human readable form. I agree that there are a number of possible representations which might make sense. But, using negative days and positive hours:minutes:seconds is just bizarre. I can't think of any possible application where that would be the desired format. --- Roy Smith r...@panix.com -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
Skip Montanaro s...@pobox.com: Note though, that the ISO8601 representation isn't without its own flaws (which might explain why Tim avoided it BITD): * It doesn't appear to provide a way to represent fractions of a second (though perhaps all the fields can be fractional) * How many days are in a month or a year? (It has format codes for both. Writing a useful strptime is probably impossible.) * It has other ambiguities (M represents both months and minutes - what were they thinking?) I don't have the (nonfree) ISO 8601 at hand, but URL: http://www.schemacentral.com/sc/xsd/t-xsd_duration.html contains the practical answers -- xsd is one important use case for str(timedelta), after all. Fractions of seconds are supported -- the other fields can't be fractional. The letter T separates months and minutes so there's no ambiguity there. str(timedelta()), unfortunately probably can't use anything but seconds since PT1M can be 61 seconds and P1D can be 23 or 25 hours (DST). As you say, P1M really means one month and P1Y means one year. The ambiguity is intentional; if you mean to pay your employees monthly, the interval is one month. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Wed, Mar 26, 2014 at 10:58 AM, Marko Rauhamaa ma...@pacujo.net wrote: Fractions of seconds are supported -- the other fields can't be fractional. Actually, it appears that whatever the last value you give can be fractionated. From the Wikipedia page you referenced: The smallest value used may also have a decimal fraction, as in P0.5Y to indicate half a year. As you say, P1M really means one month and P1Y means one year. The ambiguity is intentional; if you mean to pay your employees monthly, the interval is one month. True. Your comment about monthly intervals makes me realize that you probably can't map timedelta objects onto this ISO8601 duration stuff. It seems like if you want to specify pay my employees on the first of every month, then timedelta objects are the wrong thing. You want a recurrence relation, which is a more complex beast. For that, you want something like dateutil.rrule. There is a good reason that the internal units of timedelta objects are days, seconds, and microseconds. They are well-defined outside of a calendar context. So, I guess Roy is back to square one. He can always roll his own timedelta subclass and give it a __str__ implementation... S -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
Skip Montanaro s...@pobox.com: There is a good reason that the internal units of timedelta objects are days, seconds, and microseconds. They are well-defined outside of a calendar context. So, I guess Roy is back to square one. He can always roll his own timedelta subclass and give it a __str__ implementation... If you don't want to mix the intricacies of calendars to datetime and timedelta, why use them? (Epoch) seconds do everything for you unambiguously. Yes, yes. The physicists ought to stop fricking around with leap seconds. They should declare a 3000-year moratorium on leap seconds. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On 2014-03-26, Skip Montanaro s...@pobox.com wrote: On Wed, Mar 26, 2014 at 10:58 AM, Marko Rauhamaa ma...@pacujo.net wrote: Fractions of seconds are supported -- the other fields can't be fractional. Actually, it appears that whatever the last value you give can be fractionated. From the Wikipedia page you referenced: We're still just papering-over the basic problem: the entire time/calendar system use by western civilization is a mess. I don't know a lot about other systems in use, but from what I have seen they were all pretty much just as bad. We should fix the basic problem first, then I bet the Python library problems will sort themselves out pretty easily. Of course to simplify matters, we're going to have to stop worrying so much about seasons and whether it's light or dark outside... -- Grant Edwards grant.b.edwardsYow! Hey, wait at a minute!! I want a gmail.comdivorce!! ... you're not Clint Eastwood!! -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
Grant Edwards invalid@invalid.invalid writes: We're still just papering-over the basic problem: the entire time/calendar system use by western civilization is a mess. I don't know a lot about other systems in use, but from what I have seen they were all pretty much just as bad. We should fix the basic problem first, then I bet the Python library problems will sort themselves out pretty easily. I see from my calendar that 1 April is still several days away. So I wonder how serious you are: we should forestall dealing with the reality of calendars, until the world fixes our difficulties for us? Of course to simplify matters, we're going to have to stop worrying so much about seasons and whether it's light or dark outside... Not too serious, I suppose. So what *do* you recommend we do? It's easy to point at the real world and say it's messy and distasteful to deal with, but that's a big part of the job we take on as programmers. -- \“… Nature … is seen to do all things Herself and through | `\ herself of own accord, rid of all gods.” —Titus Lucretius | _o__) Carus, c. 40 BCE | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
- Original Message - One of my roles on this newsgroup is to periodically whine about stupidities in the Python datetime module. This is one of those times. I have some code which computes how long ago the sun set. Being a nice pythonista, I'm using a timedelta to represent this value. It would be difficult to imagine a less useful default way to print a timedelta: previous sunset: -1 day, 22:25:26.295993 The idea of str() is that it's supposed to return a human-friendly representation of a value. Humans do not say things like, The sun set 1 day ago plus 22 hours and 25 minutes. I can think of a less useful default way: previous sunset: 1 sunset ago This is how humans have been saying things for thousands of years before inventing the clock. Beside that, I think datetime has all the formatters required to do pretty much anything. Note : I don't see what's wrong in your example, however I have the feeling the term stupiditie is a little bit strong ;) JM -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
Chris Angelico wrote: By showing those last ones as 1̅.091... and 2̅.091..., you emphasize the floating-point nature of the data: everything after the decimal is the mantissa, and everything before the decimal is the exponent. The reason for writing them that way is so that you can look the last part up in your log tables to find the antilog. I can't think of any corresponding justification for timedeltas. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On 03/26/2014 04:25 PM, Dennis Lee Bieber wrote: On Tue, 25 Mar 2014 20:58:27 -0400, Roy Smith r...@panix.com declaimed the following: One of my roles on this newsgroup is to periodically whine about stupidities in the Python datetime module. This is one of those times. I have some code which computes how long ago the sun set. Being a nice pythonista, I'm using a timedelta to represent this value. It would be difficult to imagine a less useful default way to print a timedelta: previous sunset: -1 day, 22:25:26.295993 The idea of str() is that it's supposed to return a human-friendly representation of a value. Humans do not say things like, The sun set 1 day ago plus 22 hours and 25 minutes. Makes sense to me -- the key being time DELTA... IE, a difference from some (unspecified) instance in time... If you want an instance of time, you need to add some known instance and the delta value. Making sense is not the same as user friendly... Hey, when did Bob get here? About 15 minutes ago. vs About an hour ago, plus 45 minutes. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Wed, 26 Mar 2014 19:25:45 -0400, Dennis Lee Bieber wrote: On Tue, 25 Mar 2014 20:58:27 -0400, Roy Smith r...@panix.com declaimed the following: One of my roles on this newsgroup is to periodically whine about stupidities in the Python datetime module. This is one of those times. I have some code which computes how long ago the sun set. Being a nice pythonista, I'm using a timedelta to represent this value. It would be difficult to imagine a less useful default way to print a timedelta: previous sunset: -1 day, 22:25:26.295993 The idea of str() is that it's supposed to return a human-friendly representation of a value. Humans do not say things like, The sun set 1 day ago plus 22 hours and 25 minutes. Makes sense to me -- the key being time DELTA... IE, a difference from some (unspecified) instance in time... If you want an instance of time, you need to add some known instance and the delta value. I think you have missed the point of the rant. Roy is not ranting that he has a timedelta. He wants a timedelta. He is ranting that the timedelta displays in a totally unintuitive fashion. Paraphrasing: the previous sunset was (one day less 22 hours and 25 minutes) ago instead of the previous sunset was (1 hour and 35 minutes) ago where the parts in the brackets come directly from the timedelta object. I think that you misread Roy's example as: 1 day plus 22 hours 25 minutes ago instead of: 1 day ago plus 22 hours 25 minutes (that is, 22 hours and 25 minutes after 1 day ago). The problem here, I believe, is that there are two ways of interpreting remainders for negative numbers. Dividing -5 by 2 can give either -2 with remainder -1, or -3 with remainder +1. Mathematically, it is *usually* more useful to go with the version with the positive remainder, and that's what Python does. But I think it's the wrong choice for timedelta. Let's take a simple example: a timedelta of 30 hours. What's that in days and hours? py divmod(30, 24) (1, 6) That makes perfect intuitive sense: 30 hours is 1 day with 6 hours remaining. In human-speak, we'll say that regardless of whether the timedelta is positive or negative: we'll say 1 day and 6 hours from now or 1 day and 6 hours ago. But when we specify the sign: py divmod(-30, 24) (-2, 18) If an event happened 30 hours ago, it is correct to say that it occurred 18 hours after 2 days ago, but who talks that way? -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Thu, Mar 27, 2014 at 11:16 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: If an event happened 30 hours ago, it is correct to say that it occurred 18 hours after 2 days ago, but who talks that way? That response demonstrates real genius. Rue the datetime? Who talks like that? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
In article mailman.8597.1395883727.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Thu, Mar 27, 2014 at 11:16 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: If an event happened 30 hours ago, it is correct to say that it occurred 18 hours after 2 days ago, but who talks that way? That response demonstrates real genius. Rue the datetime? Who talks like that? I had a dangling pointer error, and blew my stack to half past last wednesday -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On Thu, 27 Mar 2014 00:16:57 +, Steven D'Aprano wrote: py divmod(-30, 24) (-2, 18) If an event happened 30 hours ago, it is correct to say that it occurred 18 hours after 2 days ago, but who talks that way? Well, not *exactly*, but: If today happens to be Wednesday, and an event occurred last Friday, I might say a week ago Friday. Similarly, today, I could also say it'll be two years at my new job next month. For an event that occurred approximately 310 days ago, I might say less than a year ago, and for an event that occurred approximately 350 days ago, I might say a little less than a year ago. Or did you forget to put the winky there, and I fell for it? 11 years, 2 months, 26 days, 9 hours, 3 minutes, 27.4 seconds'ly yours, Dan -- https://mail.python.org/mailman/listinfo/python-list
YADTR (Yet Another DateTime Rant)
One of my roles on this newsgroup is to periodically whine about stupidities in the Python datetime module. This is one of those times. I have some code which computes how long ago the sun set. Being a nice pythonista, I'm using a timedelta to represent this value. It would be difficult to imagine a less useful default way to print a timedelta: previous sunset: -1 day, 22:25:26.295993 The idea of str() is that it's supposed to return a human-friendly representation of a value. Humans do not say things like, The sun set 1 day ago plus 22 hours and 25 minutes. -- https://mail.python.org/mailman/listinfo/python-list
Re: YADTR (Yet Another DateTime Rant)
On 03/25/2014 05:58 PM, Roy Smith wrote: One of my roles on this newsgroup is to periodically whine about stupidities in the Python datetime module. This is one of those times. I have some code which computes how long ago the sun set. Being a nice pythonista, I'm using a timedelta to represent this value. It would be difficult to imagine a less useful default way to print a timedelta: previous sunset: -1 day, 22:25:26.295993 The idea of str() is that it's supposed to return a human-friendly representation of a value. Humans do not say things like, The sun set 1 day ago plus 22 hours and 25 minutes. I'm not sure whether to admire you for your stick-to-it-iveness, or pity you for the plight you are in. Either the first or second time I hit a datetime WTF moment I wrote my own wrapper classes. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
