This would be very confusing in suddenly giving dicts a half-ordered, half-not semantics in a particular context.
Why wouldn't you simply switch to setting everything through kwargs instead?
Not to mention that this would have a performance penalty for dicts as they would have to keep an ordered set of integer keys in case they are used with **.
Two dicts with same elements not being equal would be surprising and confusing.
I'd use an `OrderedDict` in situations where I have a mapping where the order of elements is significant. `OrderedDict` signals intent much more clearly, and its `__eq__` method cares about order.
Eg. you can't rely on
dict_b_keys = iter(dict_b)
for key in dict_a:
value_a = dict_a[key]
value_b = dict_b[next(dict_b_keys)]
print(f"{value_a} == {value_b}: ", value_a == value_b)
The funniest part is that this does not really matter for this discussion: insertion order is pretty much arbitrary when what you need is for key 0 to come first, key 1 to come next...
> Why wouldn't you simply switch to setting everything through kwargs instead?
Not all arguments in Python are passable both ways.
In
def f(a, /): print(a)
`a` may be passed only positionally.
I was demonstrating the existence of such things in general since OP seemed unaware. For the proposal, you'd of course only use it for functions that took more kinds of arguments.
...why?
I don't love this proposal, but `{1:"a", 2:"b", 0:"c"} == {0:"c", 1:"a", 2:"b"}`, and so presumably either would have the same behavior when passed to `def f(foo, bar baz): ...`.
That the runtime would correct the order as part of the splat operation seems implied?
Just imagine passing in a 500k item dict to ** by accident: dicts maintaining sorted state appeared the only sensible implementation to me.
Like the cost of doing that isn't going to be greater than the existing cost of keyword arguments, which can already be arbitrarily ordered!
Like, what about this is more "preposterous" than passing a massive dict to kwargs already?
Sorting of a large collection happening implicitly is too expensive for what would generally be a benign mistake.
Passing kwargs requires resolving n references, one for each kwarg. Passing args by index requires passing n references. Like in code:
def convert_dict_to_args(f, magic_kwargs):
out_args = []
out_kwargs = {}
for k, v in magic_kwargs:
if isinstance(k, int):
out_args[k] = v
else:
out_kwargs[k] = v
return f(*out_args, **out_kwargs)
Edit: for context,
>>> from timeit import timeit as t
>>> t(stmt='f(1,2,3)', setup='def f(a, b, c): pass', number=int(1e8))
5.765844099999981
>>> t(stmt='f(*(1,2,3))', setup='def f(a, b, c): pass', number=int(1e8))
5.840746500000023
>>> t(stmt='f(a=1,b=2,c=3)', setup='def f(a, b, c): pass', number=int(1e8))
7.400104499999998
>>> t(stmt='f(**d)', setup='d=dict(a=1,b=2,c=3)\ndef f(a, b, c): pass', number=int(1e8))
20.779321399999958
>>> t(stmt='f(**d)', setup='d=dict()\ndef f(a=None, b=None, c=None): pass', number=int(1e8))
9.583819900000094
>> out_args = []
>> out_args[3] = 'foo'
And if it's still not clear, pass
magic_kwargs = { 'arg1': 'bar', 2: 'foo', 'arg2': 'yeah', 1: 'not', 0: 'really'}
Yes, this should be a typeerror. I elided any kind of error checking, but you still don't need to sort to check that. You run into the same issue if you pass `*range(5)` to a function of one argument today.
> magic_kwargs = { 'arg1': 'bar', 2: 'foo', 'arg2': 'yeah', 1: 'not', 0: 'really'}
Again, this would be a TypeError (assuming the underlying function is defined as `def (arg1, arg2, ...) ` or something. And yet again, there's no need to sort anything to detect that error.
I feel like the thing you're getting at here is that you get index out of range errors given the half-assed implementation I did, which is absolutely true. It's buggy, it's broken, it's demo code. But you solve that by finding the max value of the integers keys of the dict, but finding the maximum value at worst requires a second linear scan, not a sort. You never need to sort the keys, you can always place them or error in linear time.
For a fuller implementation:
def convert_dict_to_args(f, magic_kwargs):
_max = 0
for k in magic_kwargs.keys():
if isinstance(k, int):
if k < 0: raise TypeError
if k > _max: _max = k
elif not isinstance(k, str):
raise TypeError
_SENTINEL = object()
out_args = [_SENTINEL for _ in range(_max)
out_kwargs = {}
for k, v in magic_kwargs.items():
if isinstance(k, int):
out_args[k] = v
else:
out_kwargs[k] = v
if _SENTINEL in out_args:
raise TypeError
return f(*out_args, **out_kwargs)
args = ('really', 'not', 'foo') kwargs = {'arg1': 'bar', 'arg2': 'yeah'}
All of these optimizations are applicable to sorting a sparse, bounded list of integers, but that's still sorting them.
No, I've copied them into a list. There was no sorting. I've never compared elements or done any nlogn operations. I've shuffled, perhaps, or ordered, but not sorted. That's a meaningful distinction.
> have to keep track of missing elements, which is at least another loop through the list).
The implementation I have is complete, it errors if the array is sparse. You need at most two loops through the dict, which if you wanted to you could avoid with a small (constant time and constant space) change to the underlying dict implementation to cache the max integer key stored and require only a single iteration.
You can technically do even faster than that by making the iteration over the number of positional args, not total args, but in practice that would probably be slower.
And it's all going to be just as fast as kwargs today.
Like jumping back a bit your argument is
> Passing a dict is passing by reference, and if the called method reads 5 elements from that dict, it's tiny constant time.
But if you pass **kwargs to a method, the dict size is unbounded, so it's O(n), not constant! Exactly the same as now. And if the method being called declares it's params explicitly, it's still constant since you can immediately error on the first unknown parameter!
If it was constant before, it's still constant. If it was linear before, it's still linear. And you never need to sort anything.
Just to further clarify, above you say
> and **kwargs has every element read in O(1) time or it gets passed along by reference.
Reading every element in O(1) time is O(n)! And is precisely the same as what's happening now.
It seems like we are now looking for imprecisions in each other's reply and discussion does not seem to be constructive: we are agreeing on rough potential implementations, it's just that we differ whether that should be acceptable or not.
That's fine, you are not convincing me and I am not convincing you, so we might as well drop it. It's not like this proposal is happening :)
Have a good day!
additionally, you might be interested to know that the implementation of dicts as ordered was found to be more performant than its predecessor.
Finally, even if they were unordered, there would be no need for ordering in this proposal, which depends on unique integer keys starting at 0.
For the proposed use case, either **kwargs would have to sort a subset of the dict with integer keys to map positional arguments to their, ahem, positions, and then either leave the rest as-is (or sort it altogether), or a dict would have its definition modified to keep this order as items are added.
I dislike both, and I definitely hate implicit sorting happening with **.
>the insertion-order preservation nature of dict objects has been declared to be an official part of the Python language spec.