[issue18629] future division breaks timedelta division by integer
Changes by Alexander Belopolsky alexander.belopol...@gmail.com: -- resolution: - wont fix stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Changes by Jean-Paul Calderone jean-p...@clusterhq.com: -- nosy: -exarkun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Antoine Pitrou added the comment: It's not a duplicate. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Changes by Serhiy Storchaka storch...@gmail.com: -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Marc-Andre Lemburg added the comment: On 03.08.2013 00:47, Alexander Belopolsky wrote: Alexander Belopolsky added the comment: Does a result of one and one half seconds make sense as the result of a floor division operation? Yes. Timedeltas behave as integers containing the number of microseconds: timedelta(microseconds=1) / 2 datetime.timedelta(0) I think that's a very obscure interpretation of floor division for timedeltas :-) IMO, floor division result should work on seconds, not microseconds. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Mark Dickinson added the comment: I think that's a very obscure interpretation of floor division for timedeltas :-) Agreed. -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Alexander Belopolsky added the comment: What is so special about seconds? Why not days? As in timedelta(3) // 2 timedelta(1) Note that in 3.x we have timedelta over timedelta division that lets you do floor division in arbitrary time units. What is the use case for timedelta // int that rounds down to a second? I suspect in most cases you really want timedelta // timedelta(seconds=int) instead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Mark Dickinson added the comment: I'm not sure I see a use-case for timedelta // int at all. To make sense of that, you first need some way to make sense of floor(timedelta), and as you say it's not clear what that should mean: number of seconds? number of days? Either of those would seem more natural than number of microseconds, though. timedelta // timedelta and timedelta / int on the other hand have an obvious meaning. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Mark Dickinson added the comment: -1 on changing the behaviour in 2.7, though; I think it's far too late for that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Marc-Andre Lemburg added the comment: On 03.08.2013 18:32, Alexander Belopolsky wrote: Alexander Belopolsky added the comment: What is so special about seconds? Why not days? As in timedelta(3) // 2 timedelta(1) Note that in 3.x we have timedelta over timedelta division that lets you do floor division in arbitrary time units. What is the use case for timedelta // int that rounds down to a second? I suspect in most cases you really want timedelta // timedelta(seconds=int) instead. The notion of fraction in time usually applies to seconds, not days, hours or minutes. Since floor removes fractions, the natural expectation is to have // int apply to seconds, not microseconds (which represent fractions of a second). That said, I don't think having // division on timedeltas is useful at all. I'd be +1 on removing this support and raise a TypeError instead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Tim Peters added the comment: Well, a timedelta is a duration. timedelta // n is as close as possible to one n'th of that duration, but rounding down (if necessary) so that the result is representable as a timedelta. In the same way, if i and j are integers, i // j is as close as possible to one j'th of i, but rounding down (if necessary) so that the result is representable as an integer. Like: from datetime import timedelta timedelta(1) // 7 datetime.timedelta(0, 12342, 857142) timedelta(1) - 7 * _ datetime.timedelta(0, 0, 6) The last line shows the part truncated away: one seventh of a day is not representable as a timedetla. If `timedelta // int` rounded to the closest representable timedelta, it would return timedelta(0, 12342, 857143) instead. That's a little bigger than a seventh of a day: timedelta(0, 12342, 857143) * 7 datetime.timedelta(1, 0, 1) It has nothing directly to do with days, hours, seconds ... it so happens that timedelta has microsecond resolution, so the closest representable approximations to one n'th of a timedelta most often have non-zero microsecond components. If timedelta had femtosecond resolution, they'd most often have non-zero femtosecond components ;-) -- nosy: +tim_one ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Jean-Paul Calderone added the comment: I think that's a very obscure interpretation of floor division for timedeltas :-) Note - I don't care about this. I just want `timedelta / int` to do the same thing in Python 2.7 with __future__.division as `timedelta / int` does in Python 3. Please don't reject this because of some unrelated discussion about how floor division should be implemented for timedelta. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Alexander Belopolsky added the comment: There are two schools of thought here. One school (MAL and Mark) thinks of durations as real number of seconds. The other school (Tim and I) think of durations as integer number of resolution intervals. This is why I and Tim before me resisted adding true division of timedelta by a number and multiplication of timedelta by a float. Mark prevailed on that issue (see #1289118.) His expertise in floating point computing certainly helped designing and implementing these operations correctly. We still have a small quirk waiting to be ironed out (see #8860), but overall I am happy with the current state. This said, the datetime module carries a long legacy of being a pure integer arithmetics in a funny variable-radix notation. We can disagree on the utility of floor division as it is currently defined, but we cannot remove or change it in an incompatible way. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Alexander Belopolsky added the comment: I just want `timedelta / int` to do the same thing in Python 2.7 with __future__.division as `timedelta / int` does in Python 3. It other words you want to backport timedelta / int true division. I am afraid it is 3-4 years too late for this request, but I will let others make a call. Count me as -0. I usually prefer explicit error over an obscure bug. If we backport true division the -Qnew flag will be changing the meaning of timedelta / int very slightly: instead of rounding down it will round to nearest. There are cases where this difference is important. Furthemore, when people compare timedeltas in tests they rarely do it with precision tolerance. If you have a good test coverage change from floor to true division may break your tests. My recommendation is: replace timedelta / int with timedelta // int in your 2.x code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Alexander Belopolsky added the comment: This issue is effectively a duplicate #1083 (see msg101281.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
New submission from Jean-Paul Calderone: datetime.timedelta instances are divisible by integers on Python 2.7, but not when __future__.division has been turned on: exarkun@top:~$ ~/Projects/cpython/2.7/python -c ' from datetime import timedelta print timedelta(seconds=3) / 2 ' 0:00:01.50 exarkun@top:~$ ~/Projects/cpython/2.7/python -c ' from __future__ import division from datetime import timedelta print timedelta(seconds=3) / 2 ' Traceback (most recent call last): File string, line 4, in module TypeError: unsupported operand type(s) for /: 'datetime.timedelta' and 'int' exarkun@top:~$ ~/Projects/cpython/2.7/python Python 2.7.5+ (2.7:8205e72b5cfc, Aug 2 2013, 11:12:04) This presents a minor barrier to Python 3 transitions, since it prevents the use of __future__.division in a module trying to retain Python 2 compatibility where timedelta division is used. -- components: Library (Lib) messages: 194181 nosy: exarkun priority: normal severity: normal status: open title: future division breaks timedelta division by integer type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Antoine Pitrou added the comment: You're just looking for floor division: $ python -Qnew Python 2.7.4 (default, Apr 19 2013, 18:28:01) [GCC 4.7.3] on linux2 Type help, copyright, credits or license for more information. 1/2 0.5 from datetime import timedelta print timedelta(seconds=3) // 2 0:00:01.50 -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Jean-Paul Calderone added the comment: Hm. Maybe I am. Yet isn't true division implemented for this pair of types in Python 3? I'm not sure why it shouldn't be implemented for them in Python 2. Also that raises another question. Does a result of one and one half seconds make sense as the result of a floor division operation? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Madison May added the comment: I agree -- it's not at all intuitive that the floor division returns a decimal number of seconds, while float division raises an error. This should probably be cleaned up. In python 3.4, both float division and integer division return decimal numbers of seconds -- that's not all that intuitive, either. Python 3.4.0a0 (default:d5536c06a082+, Jul 11 2013, 20:23:54) [GCC 4.8.1] on linux Type help, copyright, credits or license for more information. from datetime import timedelta print(timedelta(seconds=3)/2) 0:00:01.50 print(timedelta(seconds=3)//2) 0:00:01.50 -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +belopolsky, lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Alexander Belopolsky added the comment: I believe this is related to the fact that timedelta * float is not supported in 2.x: Python 2.7.5 (default, May 24 2013, 15:56:16) [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2 Type help, copyright, credits or license for more information. from datetime import * timedelta(2) * 0.5 Traceback (most recent call last): File stdin, line 1, in module TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float' I don't see why this is a barrier to Python 3 transitions. Before you turn on true division you should replace all instances of floor division with '//' anyways. Just treat instances of timedelta / int as you would instances of int / int. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Alexander Belopolsky added the comment: Does a result of one and one half seconds make sense as the result of a floor division operation? Yes. Timedeltas behave as integers containing the number of microseconds: timedelta(microseconds=1) / 2 datetime.timedelta(0) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
