[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