Elliot Gorokhovsky added the comment:
Will post the final version of this patch as a pull request on Github.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Changes by Elliot Gorokhovsky :
--
pull_requests: +479
___
Python tracker
<http://bugs.python.org/issue28685>
___
___
Python-bugs-list mailing list
Unsubscribe:
Elliot Gorokhovsky added the comment:
On Fri, Mar 10, 2017 at 12:26 AM Serhiy Storchaka
wrote:
>
> Serhiy Storchaka added the comment:
>
> The issue shouldn't be closed until it resolved or rejected.
>
Ya, sorry about that. This is my first time contributing.
>
Elliot Gorokhovsky added the comment:
Your code changes __class__, not type, which would remain equal to
"instance". (my understanding, could be wrong). The docs say the following:
https://docs.python.org/3.7/reference/datamodel.html
> Like its identity, an object’s type is also
Elliot Gorokhovsky added the comment:
Yup, I was completely wrong.
If your classes were defined in pure-Python, this would raise an exception
(since the pure-Python operators/functions check for bad types, correct me
if I'm wrong). However, if you defined your compares at the C API level
Elliot Gorokhovsky added the comment:
Actually, I just ran this in the patched interpreter, and it worked!
It printed:
zebra
gizmo
zebra
gizmo
zebra
gizmo
zebra
gizmo
zebra
gizmo
zebra
gizmo
zebra
gizmo
Inspired by the above result, I ran your counterexample (below) to see if
it would work as
Elliot Gorokhovsky added the comment:
I just ran it. With the patched interpreter, I get no error. With the
unpatched interpreter, I get ValueError. :(.
--
___
Python tracker
<http://bugs.python.org/issue28
Elliot Gorokhovsky added the comment:
On Sat, Mar 11, 2017 at 9:01 PM Tim Peters wrote:
>
> Elliot, I don't care if the example behaves differently. Although someone
> else may ;-)
>
> The only things `.sort()` has ever tried to guarantee in the presence of
> mutations
Elliot Gorokhovsky added the comment:
It was a release build -- it would blow up in a debug build.
Now, regarding the fix you propose: I'll benchmark it tomorrow. If the
impact is small, I agree that it would be an elegant fix. If not, however,
perhaps we just have to get r
Elliot Gorokhovsky added the comment:
Ya, that makes sense... I just don't get why it's faster at all, then!
Because if we add the (v==w) check, and the tp_richcompare check, how is
unsafe_object_compare any different from PyObject_RichComareBool? Is it
that we're saving
Elliot Gorokhovsky added the comment:
Eryk Sun: Thanks for your detailed response. I'm curious, though: can you
figure out why those other two examples *didn't* fail? It's driving me
crazy! For reference: https://bugs.pytho
Elliot Gorokhovsky added the comment:
I am embarrassed! That's why I said IIRC... I remembered that either
RichCompare calls RichCompareBool, or the other way around, and I was too
lazy to check :) I did remember about do_richcompare, though!
On Sat, Mar 11, 2017 at 10:07 PM Tim Peters
Elliot Gorokhovsky added the comment:
OK, I added the safety check to unsafe_object_compare. I verified that it
matches the current implementation on all the tests proposed in this thread.
--
___
Python tracker
<http://bugs.python.org/issue28
Elliot Gorokhovsky added the comment:
You can always fall back on safe_object_compare. So unless there's an
obvious reason why your edge case can't be triggered, it would be worth
putting that in as a failsafe. The additional branch should be 100%
predictable, so there should
New submission from Elliot Gorokhovsky:
When python compares two objects, there are many safety checks that have to be
performed before the actual comparison can take place. These include checking
the types of the two objects, as well as checking various type-specific
properties, like
Changes by Elliot Gorokhovsky :
--
nosy: +tim.peters
___
Python tracker
<http://bugs.python.org/issue28685>
___
___
Python-bugs-list mailing list
Unsubscribe:
Elliot Gorokhovsky added the comment:
Sure, if it compiles without that def, I'll remove it from the patch. I
added it because I did all the development in an extension module, which
also included Python.h, but for some reason it gave me a "function
implicitly defined" error f
Elliot Gorokhovsky added the comment:
On Mon, Nov 14, 2016 at 10:32 AM STINNER Victor
wrote:
> You can use perf timeit --compare-to to check if the result is significant
> or not, and it displays you the "N.NNx faster" or "N.NNx slower" if it's
> significant.
Changes by Elliot Gorokhovsky :
Added file: http://bugs.python.org/file45508/fastsort.patch
___
Python tracker
<http://bugs.python.org/issue28685>
___
___
Python-bug
Elliot Gorokhovsky added the comment:
So thanks for pointing out that perf has a --compare_to option: it turns out I
had calculated the times wrong! Specifically, I had used
(ref-dev)/ref
while I should have used
ref/dev
which is what perf --compare_to uses. Anyway, the actual times are
Elliot Gorokhovsky added the comment:
Oh wait... uh... never mind... we want "faster" to refer to total time taken,
so 1-def/ref is indeed the correct formula. I just got confused because perf
outputs ref/dev, but that doesn't make sen
21 matches
Mail list logo
