Re: [Python-ideas] Exploiting type-homogeneity in list.sort() (again!)

On Mon, Mar 6, 2017, 4:42 PM Jim J. Jewett <jimjjewett@gmail.com> wrote: (1) Good Job. Thanks! (3) Ideally, your graph would have the desired-to-be lines after the as-is lines; for English writing, that would mean putting your (short red) lines to the right of the (tall blue) lines. (4) I suspect colors other than red and blue would be helpful as well, but I am explicitly not a design wiz. My best suggestion (other than "ask someone who isn't me") would be to use blue for as-is and green for to-be. Ya, I know the colors are terrible, I just have no graphic design experience so I figured I'd make the graph the same colors as the diagram (5) I don't know that all-ASCII (or at least all-Latin1) is true for most applications, but it is certainly true for most datasets run in countries where latin1 is sufficient, which includes most places outside of Asia, Africa, and perhaps Eastern Europe. If anything, that strengthens your case, since you can win on plenty of datasets even for applications where it isn't always safe, and for those datasets that do require a wider charset, you're likely to discover this quickly. True. I think a much bigger part of the consideration is also that a lot of software (e.g. file systems) *don't* support unicode, at least by default, so if you're dealing with text you got from another program or from the OS, it's usually ASCII. And usually, our shell scripts our getting their text from other programs (e.g. file names). (6) When I saw the flowchart around f(v, w), at first I was thinking about the key function used in some sorting... I suppose that isn't relevant, since those sorts (If I Recall Correctly) already create a parallel array to avoid recomputing the keys, but ... it might be worth clarifying, if you can find a way to do it easily without adding too much complexity. Maybe just change "this f" to "the compare function f"? You are correct -- key sorts create a parallel array. In fact, *all* sorts create a parallel array, for safety: the only way to make sure the objects aren't getting mutated as you sort is to keep them safe! If the objects are getting mutated during the sort, something is clearly going horribly wrong, but at least you won't segfault. (This is not part of my patch -- it's part of the original implementation). (7) I hope you have put in a pull request to get this added to python 3.7. Thanks! I don't think I can make pull requests, but I am going to submit a fixed version to the bug tracker (Tim pointed out that my current code isn't thread-safe or adversary-safe because it stores compare_function in a global. I have to modify the code keep it in local scope and pass in to every function that needs it. This will make the diff hairier, but not increase code complexity. -jJ
participants (1)
-
Elliot Gorokhovsky