On 11.10.2016 05:02, Tim Peters wrote:
Let's not get hung up on meta-discussion here - I always thought
"massive clusterf**k" was a precise technical term anyway ;-)
I thought so as well. ;)
http://www.urbandictionary.com/define.php?term=clusterfuck
Cheers,
Sven
__
Elliot Gorokhovsky wrote:
I will be able to rule that out
when I implement this as a patch instead of an extension module and test
my own build.
You could test it against a locally built Python without
having to go that far.
--
Greg
___
Python-ideas
On Mon, Oct 10, 2016 at 10:15 PM Guido van Rossum wrote:
> But that's suspicious in itself -- since no comparisons are needed to
>
> sort a 1-element list, if it's still faster, there must be something
>
> else you're doing (or not doing) that's affecting the time measured.
>
Oh, ya. Duh. So th
On Mon, Oct 10, 2016 at 7:56 PM, Elliot Gorokhovsky
wrote:
> So here's a simple attempt at taking lots of measurements just using
> time.time() with lists of ints. The results are great, if they are valid
> (which I leave to you to judge); even for lists with just one element, it's
> 16% faster!
[please restrict follow-ups to python-ideas]
Let's not get hung up on meta-discussion here - I always thought "massive
clusterf**k" was a precise technical term anyway ;-)
While timing certainly needs to be done more carefully, it's obvious to me
that this approach _should_ pay off significantly
