On Thu, Feb 28, 2013 at 9:48 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Le Thu, 28 Feb 2013 09:30:50 -0600,
Don Spaulding <donspauldingii@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.