[issue2139] sqlite3 module needs upgrading

Martin v. Löwis added the comment: Such bugs should have been reported here much earlier. Blind upgrading to the latest version is no option, as the latest version may also introduce new features, which is unacceptable for a bugfix release. Specific bugs could have been fixed, but really not now

[issue1600] str.format() produces different output on different platforms (Py30a2)

Mark Dickinson added the comment: I know I'm coming a bit late to this discussion, but I wanted to point out that the C99 standard does actually specify how many digits should be in the exponent of a %e-formatted number: In section 7.19.6, in the documentation for fprintf, it says: The

[issue2142] naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char

New submission from Trent Mick: When comparing content with difflib, if the resulting diff covers the last line of one or both of the inputs that that line doesn't end with an end-of-line character(s), then the generated diff lines don't include an EOL. Fair enough. Naive (and I suspect

[issue2142] naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char

Trent Mick added the comment: At a glance I suspect this patch will work back to Python 2.3 (when difflib.unified_diff() was added). I haven't looked at the Py3k tree yet. Note: This *may* also applied to difflib.context_diff(), but I am not sure. __ Tracker

[issue2142] naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char

Trent Mick added the comment: Attached is a patch against the Python 2.6 svn trunk for this. -- versions: +Python 2.3, Python 2.4, Python 2.6 Added file: http://bugs.python.org/file9460/python_difflib_unified_diff.patch __ Tracker [EMAIL PROTECTED]

[issue1856] shutdown (exit) can hang or segfault with daemon threads running

Changes by Kurt B. Kaiser: -- nosy: +kbk __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1856 __ ___ Python-bugs-list mailing list Unsubscribe:

[issue2137] test_crasher in test_struct uses 8 GB memory on 64 bit systems

Ralf Schmitt added the comment: I didn't check the trunk version - I just assumed it would also be there. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2137 __ ___

[issue1600] str.format() produces different output on different platforms (Py30a2)

Eric Smith added the comment: Given Mark Dickinson's input, I think we should follow it. That effectively means leaving the Linux/MacOS input as is, and modifying the Windows output. I'll work up a patch, but I'd still like to get some input on changing the output of existing, working code.

[issue2138] Factorial

Raymond Hettinger added the comment: Since the domain and range are ints/longs, this makes more sense as a method on type 'int' than as a math module function. The other math module functions mostly have real valued inputs and mostly have counterparts in cmath. IIRC, Tim wanted the math

[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.

Jeffrey Yasskin added the comment: 1) No worries. Even without inlining the common case of __add__, etc., Fraction is now faster than Decimal for smallish fractions [sum(Fraction(1, i) for i in range(1, 100))], and for large ones [sum(Fraction(1, i) for i in range(1, 1000))] gcd takes so much of

[issue2138] Factorial

Raymond Hettinger added the comment: gcd() is probably fine where it is. People learn about GCD and LCM where they first learn fractions. So, there is a strong association. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2138

[issue2138] Factorial

Mark Dickinson added the comment: Since the domain and range are ints/longs, this makes more sense as a method on type 'int' than as a math module function. Fair enough. Raymond, do you have any thoughts on where a gcd implementation might most usefully live? Should it stay in

[issue2138] Factorial

Mark Dickinson added the comment: The other issue here is that I see factorial as being the thin end of the wedge. If factorial were implemented, it would probably only be on the order of minutes before people wanted to know where the binomial() function was. So it seems to me that either

[issue1945] Document back ported C functions

John Lenton added the comment: This is the same as the previous patch, but I added the versionadded notation in the rst, and the info in refcounts.dat to get the return value info in the docs. Added file: http://bugs.python.org/file9461/1945-2.diff __ Tracker

[issue1600] str.format() produces different output on different platforms (Py30a2)

Mark Summerfield added the comment: On 2008-02-18, Mark Dickinson wrote: Mark Dickinson added the comment: I know I'm coming a bit late to this discussion, but I wanted to point out that the C99 standard does actually specify how many digits should be in the exponent of a %e-formatted

<    1   2   3