[Python-ideas] OrderedDict for kwargs and class statement namespace

[Don Spaulding]

On Thu, Feb 28, 2013 at 9:48 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> Le Thu, 28 Feb 2013 09:30:50 -0600,
> Don Spaulding <donspauldingii at gmail.com>
> a écrit :
> >
> > For an example of the "recommended" way to get the ordering of your
> > class attributes:
> >
> http://stackoverflow.com/questions/3288107/how-can-i-get-fields-in-an-original-order
>
> This is already possible with the __prepare__ magic method.
>
> http://docs.python.org/3.4/reference/datamodel.html#preparing-the-class-namespace
>
>
Sure.  Case in point: Django has been working around it since at least
python 2.4.


> > It seems to me that the "right thing" for python to do when given an
> > ordered list of key=value pairs in a function call or class
> > definition, is to retain the order.  So what's an acceptable level of
> > performance regression for the sake of doing things the "right way"
> > here?
>
> Or, rather, what is the benefit of doing things "the right way"? There
> are incredibly few cases for relying on the order of key=value pairs in
> function calls.
>

"If you build it, they will come..."

When I originally encountered the need for python to retain the order of
kwargs that my caller specified, it surprised me that there wasn't more
clamoring for kwargs being an OrderedDict.  However, since my development
timeline didn't allow for holding the project up while a patch was pushed
through python-dev and out into a real python release, I sucked it up,
forced my calling code to send in hand-crafted OrderedDicts and called it a
day.  I think most developers don't even stop to think that the language
*could* be different, they just put in the workaround and move on.

I think if python stopped dropping the order of kwargs on the floor today,
you'd see people start to rely on the order of kwargs tomorrow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130228/92d2b761/attachment.html>