[issue44605] functools.total_ordering doesn't work with metaclasses

Change by Raymond Hettinger : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.10, Python 3.9 ___ Python tracker ___

[issue44605] functools.total_ordering doesn't work with metaclasses

Raymond Hettinger added the comment: New changeset 66dd1a0e645f26b074547dccc92448169cb32410 by Miss Islington (bot) in branch '3.10': bpo-44605: Teach @total_ordering() to work with metaclasses (GH-27633) (GH-27640) https://github.com/python/cpython/commit/66dd1a0e645f26b074547dccc92448169cb

[issue44605] functools.total_ordering doesn't work with metaclasses

Raymond Hettinger added the comment: New changeset fde84170d06f74afd6f95d5b18cf3f733018191a by Miss Islington (bot) in branch '3.9': bpo-44605: Teach @total_ordering() to work with metaclasses (GH-27633) (GH-27641) https://github.com/python/cpython/commit/fde84170d06f74afd6f95d5b18cf3f733018

[issue44605] functools.total_ordering doesn't work with metaclasses

Change by miss-islington : -- pull_requests: +26135 pull_request: https://github.com/python/cpython/pull/27641 ___ Python tracker ___ __

[issue44605] functools.total_ordering doesn't work with metaclasses

Raymond Hettinger added the comment: New changeset 1f7d64608b5c7f4c3d96b01b33e18ebf9dec8490 by Raymond Hettinger in branch 'main': bpo-44605: Teach @total_ordering() to work with metaclasses (GH-27633) https://github.com/python/cpython/commit/1f7d64608b5c7f4c3d96b01b33e18ebf9dec8490 ---

[issue44605] functools.total_ordering doesn't work with metaclasses

Change by miss-islington : -- nosy: +miss-islington nosy_count: 4.0 -> 5.0 pull_requests: +26134 pull_request: https://github.com/python/cpython/pull/27640 ___ Python tracker _

[issue44605] functools.total_ordering doesn't work with metaclasses

Łukasz Langa added the comment: IMO the PR should be accepted and have approved it accordingly. @total_ordering, as mentioned by Raymond, wasn't ever the most efficient way to implement ordering on a class. It is the most readable and easy way to get a correct implementation though so it's pr

[issue44605] functools.total_ordering doesn't work with metaclasses

Change by Raymond Hettinger : -- keywords: +patch pull_requests: +26127 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/27633 ___ Python tracker ___

[issue44605] functools.total_ordering doesn't work with metaclasses

Glyph Lefkowitz added the comment: My preference would be to fix it one way or another; the stdlib should be correct before it's performant. If, as you say, it's better to write the methods longhand anyway for ease of debugging, then it makes sense to write them out for performance, too. -

[issue44605] functools.total_ordering doesn't work with metaclasses

Raymond Hettinger added the comment: > If the preference is to not support this use-case ,,, I don't really have a preference. Was just letting you know the pros and cons. I'll put together a PR with the "type(self).__lt__(self, other)" substitutions. Let me know if that is the outcome yo

[issue44605] functools.total_ordering doesn't work with metaclasses

Glyph Lefkowitz added the comment: > We could do that and not incur performance issues. However, it would expand > the API and double the size of the code. If the preference is to not support this use-case, then I'd rather the decorator simply raise an exception and tell me this is going

[issue44605] functools.total_ordering doesn't work with metaclasses

Raymond Hettinger added the comment: [Glyph] > why not decide on implementation at decoration time? We could do that and not incur performance issues. However, it would expand the API and double the size of the code. We've had no other reports about this issue since total_ordering() was a

[issue44605] functools.total_ordering doesn't work with metaclasses

Glyph Lefkowitz added the comment: > Do you all have preference for 1) expanding the range of use cases to cover > metaclasses but incurring a performance hit for common cases, or 2) leaving > it as-is and documenting that it doesn't work for metaclasses? If we do need the slow approach for

[issue44605] functools.total_ordering doesn't work with metaclasses

Raymond Hettinger added the comment: Do you all have preference for 1) expanding the range of use cases to cover metaclasses but incurring a performance hit for common cases, or 2) leaving it as-is and documenting that it doesn't work for metaclasses? --

[issue44605] functools.total_ordering doesn't work with metaclasses

Raymond Hettinger added the comment: To add support for metaclasses, replacing 'self.__lt__(other)' with 'type(self).__lt__(self, other)' will work. The performance degradation for the common case is about 25%: $ py -m timeit -s 'from tmp import a, b' 'a >= b' # op_result = type(self).

[issue44605] functools.total_ordering doesn't work with metaclasses

Change by Raymond Hettinger : -- versions: -Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker ___ ___ Python-bugs-

[issue44605] functools.total_ordering doesn't work with metaclasses

Change by Raymond Hettinger : -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue44605] functools.total_ordering doesn't work with metaclasses

Dennis Sweeney added the comment: The one twist is that if type(b) is a strict subtype of type(a), then "a < b" first calls type(b).__gt__(b, a), then falls back to type(a).__lt__(a, b). Example: >>> class Int(int): ... def __gt__(self, other): ... print("Here!") ... retu

[issue44605] functools.total_ordering doesn't work with metaclasses

Glyph Lefkowitz added the comment: Adding versions after confirming the bug is the same on 3.10 -- versions: +Python 3.10, Python 3.11 ___ Python tracker ___ _

[issue44605] functools.total_ordering doesn't work with metaclasses

New submission from Glyph Lefkowitz : Consider the following example that attempts to make a series of types sortable by their class name: from functools import total_ordering @total_ordering class SortableMeta(type): def __new__(cls, name, bases, ns): return super().__new__(cl