<div dir="ltr"><div><div><div>​> 
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.<br><br></div>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.<br>

<br>> 
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.<br><br></div>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 <br>

<br></div>... 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.)<br>

<div><div><br>> 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.<br><br></div><div>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.<br>

<br>> You really think so?<br><br></div><div>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 <a href="https://mail.python.org/pipermail/python-dev/2012-December/123028.html">https://mail.python.org/pipermail/python-dev/2012-December/123028.html</a>), but I'm putting forth the idea because maybe it's not impossible, and someone can make it possible.<br>

<br>> 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.<br><br></div><div>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?<br>

</div><div><br>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.<br>

</div></div></div>