[issue20632] Define a new __key__ protocol

[Nick Coghlan]

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 the question on python-ideas for Python 3.8+, 
though, with Python-side ordering of database records as the main motivating 
use case.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20632] Define a new __key__ protocol

[Cheryl Sabella]

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 with 
None being a valid value in SQLite.

For example,
>>> a = [1, None, 'a']
>>> b = [1, 5, 'b']
>>> a == b
False
>>> a < b
Traceback (most recent call last):
  File "", line 1, in 
TypeError: '<' not supported between instances of 'NoneType' and 'int'

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20632] Define a new __key__ protocol

[Nick Coghlan]

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 from __hash__, but keep it in the comparison 
methods:

unhashed_field = field(hash=False): int # Excluded from __hash__ only

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20632] Define a new __key__ protocol

[Josh Rosenberg]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20632] Define a new __key__ protocol

[Josh Rosenberg]

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 
general case. Simple examples would be attributes that equivalent C++ would tag 
with the mutable keyword; they're not part of the logical state of the instance 
(e.g. debugging counters or whatever), so they shouldn't be included in the 
"key".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20632] Define a new __key__ protocol

[Nick Coghlan]

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).

If somebody comes up with a use case for this protocol idea that isn't 
adequately covered by data classes, then they can bring it up on python-ideas, 
and we can look at revisiting the question.

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20632] Define a new __key__ protocol

[Raymond Hettinger]

Change by Raymond Hettinger :


--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20632] Define a new __key__ protocol

[Cheryl Sabella]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20632] Define a new __key__ protocol

[Josh Rosenberg]

Changes by Josh Rosenberg shadowran...@gmail.com:


--
nosy: +ShadowRanger

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20632
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20632] Define a new __key__ protocol

[Nick Coghlan]

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 would really be about
defining this as being *preferred* in the cases where it applies, and
that's a fairly weak basis for changing the type constructor.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20632
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20632] Define a new __key__ protocol

[Chris Rebert]

Changes by Chris Rebert pyb...@rebertia.com:


--
nosy: +cvrebert

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20632
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20632] Define a new __key__ protocol

[Stefan Behnel]

Changes by Stefan Behnel sco...@users.sourceforge.net:


--
nosy: +scoder

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20632
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20632] Define a new __key__ protocol

[Antoine Pitrou]

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

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20632
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20632] Define a new __key__ protocol

[Martin Panter]

Changes by Martin Panter vadmium...@gmail.com:


--
nosy: +vadmium

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20632
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20632] Define a new __key__ protocol

[Nick Coghlan]

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 __lt__ appropriately, and 
then use functools.total_ordering to add the other comparison methods.

However, many such implementations follow a very similar pattern:

def __hash__(self):
return hash(self._calculate_key())
def __eq__(self, other):
if isinstance(other, __class__):
return self._calculate_key() == other._calculate_key()
return NotImplemented
def __lt__(self, other):
if isinstance(other, __class__):
return self._calculate_key()  other._calculate_key()
return NotImplemented

A __key__ protocol as an inherent part of the type system could greatly 
simplify that:

def __key__(self):
return self._calculate_key()

The interpreter would then derive appropriate implementations for __hash__ and 
all the rich comparison methods based on that key calculation and install them 
when the type object was created.

If the type is mutable (and hence orderable but not hashable), then setting 
__hash__ = None would disable the implicit hashing support (just as it can 
already be used to explicitly disable hash inheritance).

(Inspired by Chris Withers's python-dev thread: 
https://mail.python.org/pipermail/python-dev/2014-February/132332.html)

--
components: Interpreter Core
messages: 211253
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Define a new __key__ protocol
type: enhancement
versions: Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20632
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20632] Define a new __key__ protocol

[Nick Coghlan]

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 calculate_key would be more 
appropriate.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20632
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com