[issue3250] datetime.time does not support arithmetic
George Boutsioukis <[EMAIL PROTECTED]> added the comment: I have also come across this in the past. Although I sense that some obscure reason might prevent time arithmetic from being included, here's a patch to add time/timedelta addition and subtraction. It closely follows the datetime arithmetic functions. To handle overflows, I figured it should wrap around a 24-hour limit. The timezone stuff is copied verbatim from the datetime functions, some finger-crossing applied. -- keywords: +patch nosy: +gboutsioukis Added file: http://bugs.python.org/file10806/datetime.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3250> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3250] datetime.time does not support arithmetic
George Boutsioukis <[EMAIL PROTECTED]> added the comment: Hi Chris, I know copy-pasted sounds horrible--perhaps I should have said 'modeled afterwards'(better marketing;). The thing is, the datetime & time classes share a lot of common functionality; it is inevitable that some code looks like it's repeated, because the same process is followed(take a look at the datetime & date functions already there). I can't see much room for refactoring the arithmetic functions across classes(seems too messy). Besides, the existing timezone, normalization and delta functions are used, so no significant logic is repeated.The patch indeed requires some cleanup, but overall it's good code(and not a lot of it). I submitted it without tests/doc because I think there should be a chance for this functionality to be discussed. Also, the datetime module looks like for some reason these functions were left out(some discussion I'm missing?). So before investing any more time on this some feedback would be appreciated. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3250> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1869] Builtin round function is sometimes inaccurate for floats
George Boutsioukis <[EMAIL PROTECTED]> added the comment: The issue is that the implementation of round includes multiplying the number by 10**ndigits, thus unnecessarily losing some precision for large numbers within the IEEE754 double limits. This means that even smaller numbers can produce these results for higher ndigit values, eg. >>> round(56294995342131.5, 3) #one less digit 56294995342131.508 In the submitted patch I used modf to split the number and keep the integral intact. -- keywords: +patch nosy: +gboutsioukis Added file: http://bugs.python.org/file10944/round_patch.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1869> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1869] Builtin round function is sometimes inaccurate for floats
George Boutsioukis <[EMAIL PROTECTED]> added the comment: Hi Mark, Yes, I see where you are going with this and I agree. I think the py3k round function is a bit more accurate, any chance this can be backported to 2.7(after modifying the half-rounding)? Anyway, I was just playing around with the code when I wrote this patch. Anything beyond math.h(and only the really portable functions) is obviously out of the question, so there's little here to work with. Despite the (rare) unpredictable results, I think this issue is probably too minor to spend any more time on;IMO nobody really relies on round() for accuracy anyway. Perhaps this should be just ignored. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1869> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6409] 2to3 -j 4 generates malformed diffs
George Boutsioukis added the comment: Flushing stdout is still necessary, though not enough. The processes will still have to use some kind of synchronization, and the performance toll of adding a lock to synchronize output is negligible, given that printing to stdout takes a tiny amount of time compared to the rest of the 2to3 code. This patch seems to fix the issue without affecting performance. -- nosy: +gboutsioukis Added file: http://bugs.python.org/file16889/output_lock.diff ___ Python tracker <http://bugs.python.org/issue6409> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6409] 2to3 -j 4 generates malformed diffs
Changes by George Boutsioukis : Removed file: http://bugs.python.org/file16889/output_lock.diff ___ Python tracker <http://bugs.python.org/issue6409> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6409] 2to3 -j 4 generates malformed diffs
George Boutsioukis added the comment: I updated the patch to keep the new code as local as possible. -- Added file: http://bugs.python.org/file16895/output_lock.diff ___ Python tracker <http://bugs.python.org/issue6409> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9431] 2to3 reapplies fix_dict
New submission from George Boutsioukis : This only happens on somewhat complex files, I haven't been able yet to isolate the source of this but here goes: For django trunk, running 2to3 on django/contrib/admin/options.py yields the following: @@ -282,7 +282,7 @@ if self.declared_fieldsets: return self.declared_fieldsets form = self.get_form(request, obj) -fields = [..].keys() + list([...]) +fields = list(list([...]keys())) + list([...]) instead of +fields = list([...].keys()) + etc. and there are a couple of more instances in the same file. However running 2to3 on the single line above, out of the file gives the correct result. This is only an issue with the fix_dict fixer. -- components: 2to3 (2.x to 3.0 conversion tool) messages: 112099 nosy: gboutsioukis priority: normal severity: normal status: open title: 2to3 reapplies fix_dict type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue9431> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9431] 2to3 reapplies fix_dict
George Boutsioukis added the comment: Tried it on 2 machines(Debian & Ubuntu) with both the sandbox and py3k versions. Maybe my setup is tainted on both, I'll try to find a clean one and try again from scratch. Meanwhile, can you/someone pipe 2to3's output for the whole django trunk to grep list\(list\( and see if anything comes out? (BTW in my output there are also instances of .itervalues() & .iterkeys() becoming list(...values/keys()) which is somewhat less benign) -- ___ Python tracker <http://bugs.python.org/issue9431> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
