[issue20632] Define a new __key__ protocol

Nick Coghlan added the comment: Allowing for None-first and None-last ordering is a fair use case, but I'm not sure a __key__ protocol is the right answer to that - as your own example shows, it gets tricky when dealing with nested containers. It may make sense to raise

[issue20632] Define a new __key__ protocol

Cheryl Sabella added the comment: Thanks, Nick. When I first came across this issue, I thought that dataclasses would take care of what you wrote below, but after looking at the original discussion on python-dev, I thought the problem was ordering None within a comparison

[issue20632] Define a new __key__ protocol

Nick Coghlan added the comment: It isn't InitVar that you want for that use case (that's just for passing extra information to __post_init__). Instead, you want: extra_field = field(compare=False): int # Excluded from __hash__, __eq_, etc You can also exclude a field

[issue20632] Define a new __key__ protocol

Josh Rosenberg added the comment: Ah, never mind. Looks like dataclasses.InitVar fields seem to be the answer to excluding a field from the auto-generated methods. -- ___ Python tracker

[issue20632] Define a new __key__ protocol

Josh Rosenberg added the comment: Do data classes let you define some fields as being excluded from the equality/ordering/hashing? I got the impression that if a field existed, it was part of the "key" no matter what, which isn't necessarily correct in the

[issue20632] Define a new __key__ protocol

Nick Coghlan added the comment: For now, I'm going to close this as "out of date", with the guidance being "Define a data class instead" (since that gets rid of the historical boilerplate a different way: auto-generating suitable methods based on the field declarations).

[issue20632] Define a new __key__ protocol

Change by Raymond Hettinger : -- nosy: +rhettinger ___ Python tracker ___ ___

[issue20632] Define a new __key__ protocol

Cheryl Sabella added the comment: I wonder if this would make sense as a parameter to dataclass now. -- nosy: +csabella versions: +Python 3.8 -Python 3.5 ___ Python tracker

[issue20632] Define a new __key__ protocol

Changes by Josh Rosenberg shadowran...@gmail.com: -- nosy: +ShadowRanger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20632 ___ ___

[issue20632] Define a new __key__ protocol

Nick Coghlan added the comment: I suspect it could just be a class decorator (along the lines of total_ordering), and it should certainly be prototyped on PyPI as such a decorator (using a different name for the key calculating method). If it eventually happened, elevation to a core protocol

[issue20632] Define a new __key__ protocol

Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20632 ___ ___ Python-bugs-list

[issue20632] Define a new __key__ protocol

Changes by Stefan Behnel sco...@users.sourceforge.net: -- nosy: +scoder ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20632 ___ ___

[issue20632] Define a new __key__ protocol

Antoine Pitrou added the comment: This is a very nice idea, but does it have to be part of the interpreter core, or could it simply be supplied by a decorator in the functools module? (the main advantage of having it in the interpreter is speed) -- nosy: +pitrou

[issue20632] Define a new __key__ protocol

Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20632 ___ ___ Python-bugs-list

[issue20632] Define a new __key__ protocol

New submission from Nick Coghlan: This is an idea that would require a PEP, just writing it down here as a permanent record in case someone else wants to run with it. Currently, the *simplest* way to define a non-identity total ordering on an immutable object is to define __hash__, __eq__ and

[issue20632] Define a new __key__ protocol

Nick Coghlan added the comment: Note: in conjuction with a class decorator (along the lines of functools.total_ordering), this idea is amenable to experimentation as a third party module. However, any such third party module shouldn't use a reserved name like __key__ - a public name like