I propose a flag to always return tuple regardless of how many keys/names/indices were sourced to arguments.
The way it is now exception is often needed for tuple-only cases when there is only 1 arg. So that the output is consistently a tuple of values.
E.g.:
IG1 = itemgetter(1, always_tuple=True)
print(IG1(['a', 'b'])) # ('b',)
E.g.: gh-124652: partialmethod simplifications by dg-pb · Pull Request #124788 · python/cpython · GitHub
Yes, please.
I find myself coding around this too often.
Same for attrgetter, I trust and hope.
BTW, I doubt always_tuple is the right colour for the bike shed.
I like it, but I don’t like the kwarg.
Do you not like the name of the kwarg, or that the proposal requires a kwarg at all?
If it’s the former, do you have a better name suggestion? I can’t think of any.
If it’s the latter, how about making new functions named itemsgetter and attrsgetter instead?
I don’t have a strong preference myself since each comes with its pros and cons.
I don’t like that the proposal requires a kwarg, but I don’t know that the alternatives are any better.
I think the distinction of itemsgetter would be easily overlooked. I don’t mind it having a longer name tuple_itemgetter may be a bit verbose, but nobody should be overlooking an s with it. could also have itemgetter.as_tuple, but that has it’s own awkwardness.
The kwarg is fine, it’s not what I would prefer, but it would be usable.
The “always” seems inappropriate. Any itemgetter already always gives tuples or always gives single values. No itemgetter sometimes gives tuples and sometimes doesn’t. Unless you mean an itemgetter with one index and the source values sometimes happen to already be tuples and sometimes happen to be non-tuples, and the always_tuple is supposed to wrap the latter in tuples but not do that with the former?
No strong feelings on whether this should be supported, but I think unwrap is a better kwarg, with default value True.
Side note about that PR: It is doing a lot of things; if I received a PR like that, I would probably ask the contributor to break it up into individual improvements that can be reviewed in isolation. So if your plan is to modify the signature/behavior of itemgetter, I would probably not try to do so in that PR.
I like unwrap much better.
Ideally, it was named itemsgetter, then it would be clear that it calls __getitem__ many times and stores them in a tuple, while currently it is an object which is meant to do both single and multiple accessing and is named after single. This design makes it fairly difficult to add features to it.
Btw, I don’t like the fact that this requires kwarg either, but as of now I can not see better alternatives. Except one backward-compatibility breaking change:
Having 2 separate itemgetter and itemsgetter would make things more robust and life easier going forward. I even think that making this change now would be worthwhile.
Nothing else will go into that PR.