[issue23132] Faster total_ordering

Serhiy Storchaka added the comment: May be implement your idea about local NotImplemented? And it would be good to add explaining comments in _le_from_lt() and _ge_from_gt() as in your original suggestion. -- ___ Python tracker

[issue23132] Faster total_ordering

Changes by Raymond Hettinger : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue23132] Faster total_ordering

Roundup Robot added the comment: New changeset 09b0da38ce8d by Raymond Hettinger in branch '3.4': Issue #23132: Mitigate regression in speed and clarity in functools.total_ordering. https://hg.python.org/cpython/rev/09b0da38ce8d -- ___ Python tracker

[issue23132] Faster total_ordering

Changes by Raymond Hettinger : Added file: http://bugs.python.org/file37599/total_ordering2.diff ___ Python tracker ___ ___ Python-bugs-list m

[issue23132] Faster total_ordering

Nick Coghlan added the comment: The metadata adjustments in Serhiy's patch had me thinking in terms of functools.wraps, but that rationale doesn't actually apply here (since the functions are only used in one place, and have a distinctive name rather than a generic one). I'd also missed that

[issue23132] Faster total_ordering

Serhiy Storchaka added the comment: The convert mapping is redundant, function name can be calculated from root and opname. __name__ and __doc__ can be assigned at import time. -- ___ Python tracker __

[issue23132] Faster total_ordering

Raymond Hettinger added the comment: I don't see "creating new functions" as an advantage. ABCs don't do this, nor does any other subclassing. It seems like an attempt to create a false illusion about where the code resides. This feels like feature creep with no real advantage that anyone

[issue23132] Faster total_ordering

Nick Coghlan added the comment: Oops, at least one error in my example: the return tuple should be "__gt__, __le__, __ge__". -- ___ Python tracker ___ __

[issue23132] Faster total_ordering

Nick Coghlan added the comment: While I like the readability of Raymond's version, I think the main pay-off we're getting from the template based version is that each decorator invocation is creating *new* function objects. That creation of new function objects is what allows Serhiy's patch to

[issue23132] Faster total_ordering

Raymond Hettinger added the comment: Serhiy, this is a really nice idea. By removing the additional layer of indirection, the code is more intelligible, runs faster, and the tracebacks make more sense when the user's root comparison raises an exception. Since there are only twelve functions i

[issue23132] Faster total_ordering

Changes by Raymond Hettinger : -- Removed message: http://bugs.python.org/msg233383 ___ Python tracker ___ ___ Python-bugs-list mailin

[issue23132] Faster total_ordering

Raymond Hettinger added the comment: Thanks Serhiy. I really like this clean-up. When there is an exception in the user's root comparison operation, the traceback is more intelligible now. If you're interested, here are two additional optimizations: _op_or_eq = '''

[issue23132] Faster total_ordering

Roundup Robot added the comment: New changeset 4e85df8b3ea6 by Serhiy Storchaka in branch 'default': Issue #23132: Improve performance and introspection support of comparison https://hg.python.org/cpython/rev/4e85df8b3ea6 -- nosy: +python-dev ___ Pyth

[issue23132] Faster total_ordering

Serhiy Storchaka added the comment: Side effect of improving introspection is that generated unbounded methods are pickleable now. Updated patch contains a test for this. -- Added file: http://bugs.python.org/file37570/total_ordering_faster_2.patch _

[issue23132] Faster total_ordering

Nick Coghlan added the comment: I tweaked Serhiy's benchmark script to also include the timing relative to spelling out all four ordered comparison methods. For an unpatched debug build of trunk, I get the following: $ ../py3k/python total_ordering_relative_bench.py a < b 1.643 1.605 x0.98

[issue23132] Faster total_ordering

Nick Coghlan added the comment: This looks like a nice, relatively simple improvement in both speed and introspection support, so +1 from me. Something I've wondered since we changed total_ordering to handle NotImplemented correctly is whether it would be worth exposing more of the *component

[issue23132] Faster total_ordering

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file37562/total_ordering_bench.py ___ Python tracker ___ ___ Python-bugs-list

[issue23132] Faster total_ordering

New submission from Serhiy Storchaka: Proposed patch makes comparation method generated by the total_ordering decorator faster up to 20%. Benchmark results: Unpatched Patched a < b 2.46 2.45 b < a 2.48 2.49 a >= b 4.86 4.16 b >= a 5.1 4.16 a <= b 4.93 4.1