-
-
Notifications
You must be signed in to change notification settings - Fork 30k
-
-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add sorting helpers for collections containing None values #64829
Comments
Currently, it's a bit annoying to sort collections containing "None" values in Python 3. While the default behaviour isn't going to change, it would be good to offer standard "none_first" and "none_last" helps (inspired by the SQL NULL FIRST and NULL LAST ordering control). Suggested home: functools (since that is where the total_ordering class decorator already lives), but collections would also be a reasonable choice (as this feature mostly relates to sorting containers) The minimal option (suggested by Peter Otten): def none_first(v):
return v is not None, v
def none_last(v):
return v is None, v A more complex alternative would be to provide general purpose SortsFirst and SortsLast singletons: @functools.total_ordering
class _AlwaysLesser:
def __eq__(self, other):
return isinstance(other, _AlwaysLesser):
def __lt__(self, other):
return not isinstance(other, _AlwaysLesser):
@functools.total_ordering
class _AlwaysGreater:
def __eq__(self, other):
return isinstance(other, _AlwaysGreater):
def __gt__(self, other):
return not isinstance(other, _AlwaysGreater):
SortsFirst = _AlwaysLesser()
SortsLast = _AlwaysGreater()
def none_first(v):
return SortsFirst if v is None else v
def none_last(v):
return SortsLast if v is None else v The advantage of the latter more complex approach is that you can embed the SortsFirst and SortsLast values inside a tuple as part of a more complex key, whereas the simple solution only handles the case where the entire value is None. (Inspired by Chris Withers's python-dev thread: https://mail.python.org/pipermail/python-dev/2014-February/132332.html) |
I think we should seriously consider whether to restore None's ability to compare with other entries. Removing this capability has been a major PITA and is an obstacle for people converting code to Python 3. The need to create helper function work-arounds is a symptom, not a cure. |
I've haven't yet seen anyone complain about the inability to compare None except in the specific context of sorting. If it is in fact specific to sorting, then this specific symptom and "the problem" are in fact the same thing ;-) |
Both Nick's proposals look ok to me. |
It occurred to me the current names are a bit misleading when using I think I'll propose a patch for six before doing anything to the standard |
And in case that last comment worried anyone - I won't commit *anything* |
The first rule of tautology club is the first rule of tautology club ;-) FWIW, we had to add a work-around for this in pprint._safe_key class. Without that work-around, it was difficult to work with JSON-style data hierarchies: # wouldn't pprint() without the _safe_key() work-around:
temperatures = {'Jan': 25.2, 'Feb': 22.3, 'Mar': None, 'Apr': 19.1,
'May': 22.2, 'Jun': None, 'July': 22.3} I think this will be typical for the kind of issue people will encounter when using None as a placeholder for missing data. FWIW, if None stays non-comparable, Nick's additions look fine to me. I just think it easier for everyone to restore None's universal comparability rather than adding work-arounds for the problems caused by removing that capability. |
I suspect if we'd thought of it back in the 3.0 or 3.1 time frame then At this stage of the Py3 life cycle, though, it seems simpler overall to |
Given that so few users have converted, it is |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: