On Thu, Feb 28, 2013 at 11:30 AM, Christian Heimes <christian@python.org>wrote:
Raymond was/is working on a modification of the dict's internal data structure that reduces its memory consumption. IIRC the modification adds partial ordered as a side effect. The keys are ordered in insertion order until keys are removed.
While this is potentially convenient, in order for people to really be able to use it for these purposes it would have to be reliable behavior going forward. The question is therefore: do we actually want to explicitly make this behavior part of the dict API such that all future implementations of dict (and all implementations in any Python, not just CPython) must be guaranteed to also behave this way? I suspect the answer should be "no". On Thu, Feb 28, 2013 at 7:30 AM, Don Spaulding <donspauldingii@gmail.com> wrote:
So what's an acceptable level of performance regression for the sake of doing things the "right way" here?
For class declarations, I think a little performance hit might not be too big a deal, but those are really not the most important use case here, since there are already ways to work around this for classes if one wants to. However, for function calls, which I actually believe is the more important question, I think we would have to think very hard about anything that introduced any real performance overhead, because functions are typically called a _lot_. Adding even a small extra delay to function calls could impact the overall performance of some types of Python programs substantially.. I also agree with Guido that there may be some unexpected consequences of suddenly changing the type of the kwargs parameter passed to functions which were coded assuming it would always be a plain-ol' dict.. I think it might be doable, but we'd have to be very sure that OrderedDict is exactly compatible in every conceivable way.. Perhaps instead we could compromise by keeping the default case as it is, but providing some mechanism for the function declaration to specify that it wants ordering information passed to it? I'm not sure what a good syntax for this would be, though ("(*args, ***okwargs)"? "(*args, **kwargs, *kworder)"? Not sure I'm really big on either of those, actually, but you get the idea..) --Alex