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

Ethan Furman ethan at stoneleaf.us
Fri Mar 1 00:20:32 CET 2013


On 02/28/2013 01:51 PM, Ned Batchelder wrote:
>
> On 2/28/2013 11:41 AM, Ethan Furman wrote:
>> On 02/28/2013 08:14 AM, Don Spaulding wrote:
>>>
>>>
>>>
>>> On Thu, Feb 28, 2013 at 9:48 AM, Antoine Pitrou <solipsis at pitrou.net <mailto:solipsis at pitrou.net>> wrote:
>>>
>>>     Le Thu, 28 Feb 2013 09:30:50 -0600,
>>>     Don Spaulding <donspauldingii at gmail.com <mailto: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.
>>
>> +1
>>
>> I'd already be relying on it if it were there.
>>
>
> Could you advance the discussion by elaborating your use case?  I've never had need for ordered kwargs, so I'm having a
> hard time seeing how they would be useful.

I no longer remember my original use-case, but currently I'm working on a command-line parser (I know, there are already 
plenty -- it's a learning experience) with multiple subcommands, and the order of the subcommands can make a difference.

--
~Ethan~



More information about the Python-ideas mailing list