I am thinking maybe it would be better to leave dict out of initial implementation?
Internal storage of defaults can not be dict due to hash-ability restriction, thus it will inevitably have to be tuple.
Of course there is an option to branch the code depending on defaults input. s.t.:
getobj = itemtuplegetter(..., defaults={'a': 1})
print(getobj.defaults) # {'a': 1}
getobj = itemtuplegetter(..., defaults=(1,))
print(getobj.defaults) # (1,)
But this IMO is making a bit of a mess. I.e. One has to choose between (hash-ability + performance) and (order independence). (performance, because __getitem__ of dict is expensive, while tuple access is pretty much free in C).
So I am thinking maybe better not to bother with dict for a start.
And give it some time to come up with solution that does not force user to make unnecessary choices.
So in short, I would suggest itemtuplegetter(items: Iterable, defaults: Iterable) to start with.
To me it seems to offer maximum functionality without needing to make premature choices and risking of getting stuck with them.
It could already do quite a lot:
# Arguments with defaults (by reversing order)
sys_argv = [<PATH>, 1, 2]
arg_getter = itemtuplegetter([3, 2, 1], ['c', 'b'])
c, b, a = arg_getter(sys_argv)
print((a, b, c)) # 1, 2, 'c'