On Thu, Feb 28, 2013 at 3:51 PM, Jan Kaliszewski <zuo@chopin.edu.pl> wrote:
While having class namespace ordered sounds very nice, ordered **kwargs sometimes may not be a desirable feature -- especially when you want to keep a cooperatively used interface as simple as possible (because of the risk that keyword argument order could then be taken into consideration by *some* actors while others would still operate with the assumption that argument order cannot be known...).
You mean like we had with dicts? Now that they are randomized things like docstrings started to break unexpectedly. With **kwargs the OrderedDict is created by the interpreter and passed to the called function. So the the writer of the function is the only one in control of how the ordering is interpreted. Granted, an existing function might, as currently written, expose the ordering or even the kwargs. So that aspect has to be considered. However it would still remain in the complete control of the function how the ordering of **kwargs is exposed.
Ad issue #16991: will the present semantics of inheriting from OrderedDict be kept untouched? (I mean: which methods call other methods => which methods you need to override etc.)
If not we'll have a backward compatibility issue (maybe not very serious but still...).
Any OrderedDict written in C must have identical semantics, including regarding subclassing. I've gone through my implementation on several occasions to check this and I'll probably do so again. Keep in mind that the unit tests for OrderedDict will be run against both the pure Python and C version (see PEP 399). That includes some tests regarding subclassing, though there could probably be a few more of those. Bottom line, if it doesn't quack it's not a duck we want. -eric