[issue9915] speeding up sorting with a key

Daniel Stutzbach added the comment: Antoine Pitrou wrote: > Right, that wouldn't suit your present purposes. But apparently you > are proposing to add a list sorting benchmark to the Tools directory, > with lots of duplicated code from that repo... Oh, I just stuck that under Tools because it

[issue9915] speeding up sorting with a key

Raymond Hettinger added the comment: Thanks for the revisions and timing updates. I'm heartened that the common-case of sorting without a key function isn't negatively impacted. That result is surprising though -- I thought the concept was manipulate the key and value arrays at the same tim

[issue10509] PyTokenizer_FindEncoding can lead to a segfault if bad characters are found

Ron Adam added the comment: Is this a duplicate of issue 9319? -- nosy: +ron_adam ___ Python tracker ___ ___ Python-bugs-list mailing

[issue10501] make_buildinfo regression with unquoted path

Kristján Valur Jónsson added the comment: I did various tests and quoting parts of the path seemed fragile, especially if the quote landed next to a backslash. This is dangerous ground :) -- ___ Python tracker _

[issue9915] speeding up sorting with a key

Daniel Stutzbach added the comment: Raymond Hettinger added the comment: > That result is surprising though -- I thought the concept was > manipulate the key and value arrays at the same time instead of just > the keys If the "key" parameter was not used, then the values pointer is a null poin

[issue9915] speeding up sorting with a key

Raymond Hettinger added the comment: > If the "key" parameter was not used, then the values pointer > is a null pointer. . . . > Since the branch will always be the same throughout any given > call to sort(), CPU branch prediction is effective making the > branches fairly inexpensive. I se

[issue10508] compiler warnings about formatting pid_t as an int

Jesús Cea Avión added the comment: Python 3.1 affected also. -- versions: +Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mai

[issue1859] textwrap doesn't linebreak on "\n"

Matthew Barnett added the comment: I'd be interested in having a go if I knew what the desired behaviour was, ie unit tests to confirm what was 'correct'. How should it handle line breaks? Should it treat them like any other whitespace as at present, should it honour them, or should it get an

[issue9852] test_ctypes fail with clang

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue10238] ctypes not building under OS X 10.6 with LLVM/Clang 2.8

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue8914] Run clang's static analyzer

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue9915] speeding up sorting with a key

Daniel Stutzbach added the comment: > How did it get *faster* than the original (in the case with no > key-function)? I was able to shave off some instructions in countrun(), binarysort(), and the setup and cleanup code in listsort() proper. For small n, these made a difference. > Is there

[issue10498] calendar.LocaleHTMLCalendar.formatyearpage() results in traceback with 'unsupported locale setting' on Windows

Changes by MunSic JEONG : -- nosy: +ruseel ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue1508475] transparent gzip compression in urllib

Changes by MunSic JEONG : -- nosy: +ruseel ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue10087] HTML calendar is broken

Alexander Belopolsky added the comment: I wonder: do we really need "encoding" option to the calendar output? It is really not the job of the calendar module to deal with encodings. The calendar module should produce text calendars as unicode strings and HTML calendars as UTF-8 bytes. If s

[issue10510] distutils.command.upload/register HTTP message headers: bad line termination

New submission from Brian Jones : In trying to write a PyPI service, I of course need to support the registration and upload features of setup.py, which uses distutils for those actions. One thing making this a bit more difficult than need be is the fact that distutils.command.register and dis

[issue8525] Display exception's subclasses in help()

Alexander Belopolsky added the comment: The proposal is to display builtin subclasses as for example: >>> help(ArithmeticError) class ArithmeticError(Exception) | Base class for arithmetic errors. | | Method resolution order: | ArithmeticError | Exception | BaseExceptio

[issue9222] IDLE: Fix open/saveas 'Files of type' choices

Terry J. Reedy added the comment: 3.2, 3.1, 2.7: r86702, r86703, r86704 -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker

[issue10504] Trivial mingw compile fixes

Johann Hanne added the comment: I've revised the patch to use "defined(_MSC_VER) || defined(__MINGW32__)" as suggested. And no, it does not solve all mingw compilition issues, but most of them. I've tried to only address the most obvious ones, which are *very* unlikely to break anything. I

[issue1859] textwrap doesn't linebreak on "\n"

Terry J. Reedy added the comment: Georg, if your comment means that you think that the doc patch is ready to apply, as is, without testing with a doc build, then I will do so for all 3 versions. Should there really be two blank lines after the note? -- __

[issue10504] Trivial mingw compile fixes

Martin v. Löwis added the comment: > Please give me some starting point by applying these patches. I don't > care if it's for 2.7.1 or 2.7.2. I'll try hard to get *everything* > fixed, but we have to start somewhere. I'm skeptical that we should do that with 2.7, then. So it would be better to

[issue10504] Trivial mingw compile fixes

Johann Hanne added the comment: Why exactly are you skeptical? Because it doesn't fix everything in one go? The other changes are also minimal (I'm not even sure if it requires more source changes, maybe I have just to get my #defines right). If you prefer to see a single patch which you can

[issue10504] Trivial mingw compile fixes

Amaury Forgeot d'Arc added the comment: Since the patch does not completely fix the mingw32 build, I suggest to apply it only on 3.2, and continue to work on mingw32 support there. Only after we will be able to discuss whether all the changes can be backported to 2.7, provided that they fix t

[issue1859] textwrap doesn't linebreak on "\n"

Georg Brandl added the comment: Yes, please do apply. You don't need to run a doc build for every small change; of course it is nice if you do, but errors will be caught by the daily build routine anyway and mailed to me. As for the two blank lines: you'll see that the original conversion fr

[issue10468] Document UnicodeError access functions

Georg Brandl added the comment: Thanks, reviewed and applied in r86705. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ __

<    1   2