[Python-ideas] Preserving **kwargs order (was: Re: OrderedDict literals)

[Franklin? Lee]

​> Also, I think you've got packing and unpacking backward. There's no way
**unpack can be smart about the type of thing being unpacked, because it
explicitly allows for any kind of mapping, supplied by the user, and
unpacks its keys as if they were keyword arguments.

No, I mean that the interpreter can inspect the type of the kwargs during
unpacking. Primarily, it can pass along the same type (I know it shouldn't
be the same *object*). It's also possible that, in the future, it can pass
a *view* of the kwargs dictionary *if* the callee would receive the exact
same keys (or maybe even more generally), and then only do a deeper copy of
the item pointers and order array if either the view or the original is
changed.

> Anyway, even if things did work this way, one of Guido's objections is
that he writes lots of code that keeps the kwargs dict around and adds to
it later. (Presumably he has a method that takes **kw and stores it in an
instance attribute, although he didn't give examples.) Using something
which is not a dict, but only fakes it just well enough for passing keyword
arguments, surely isn't going to satisfy him.

Well, what exactly do you mean "not a dict"? It won't be a literal dict
type, no, but it might be a subclass. It would be better if the
InternedDict could be as fast as possible (for the usual case), but I don't
think that it would absolutely cripple the idea to make it Mutable

... A-and on the flip side, I put forth that maybe Guido shouldn't be doing
that kind of thing in the first place (*gasp*)! If he wanted a copy, he
should've explicitly copied it with dict(), instead of relying on behavior
that I've never even seen a doc reference for! (Not sure if I actually
believe that **kwargs should be some subclass of FrozenDict, but maybe
someone else does, and they can convince us.)

> For example, there's plenty of Python 2.x code that fakes keyword-only
arguments by calling kwargs.pop; that code still runs in Python 3.4, and I
don't think you want to break it in 3.5. So you're effectively going to
have to build a full MutableMapping.

So... you're saying there's a chance we can break it in 3.6, right? No
reason not to look to the future if backwards compatibility is what's
keeping it from happening now.

> You really think so?

Yes, I believe that it is not impossible that someone knows how to make
pointer lookups faster than general hash lookups (a function call) of
general dicts. This may be because I haven't looked at the dict
implementation, or because the dict implementation could be better (see
https://mail.python.org/pipermail/python-dev/2012-December/123028.html),
but I'm putting forth the idea because maybe it's not impossible, and
someone can make it possible.

> But, if it is, hashing the strings to put them into an interned string
table, and then hashing those interned pointers to put into the mini-dict,
isn't going to be faster.

Why not? If an InternedDict is passing args to a newly-created IDict, the
hashing could be a single instruction: modulo by 63 (or something). (And
then maybe multiple instructions to crawl through a linked list.) And
knowing you don't HAVE to call a str.hash is surely better than calling
even a cached str.hash, no?

Point is, again, I don't know that it won't be faster. You seem to know
that it won't be faster, but I don't see you saying that there CAN'T be
such cleverness when kwargs are nice and forwarded nicely, even with
deletions or additions allowed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140415/6cb93c9c/attachment.html>