Hey, guys I must argue that make **kwargs sorted is really a terrible idea. Please think that when user wants a unsorted **kwargs, how can he or she bring the original unsorted dict back? When a dict is unsorted, we can sort it with implementation in Python/C interface or just python code for portability. That is what should be like! Give users more control over behavior of dict. That is what I propose. Best regards Hongbao Chen XJTU -----邮件原件----- 发件人: python-ideas-bounces+microcore=yahoo.com.cn@python.org [mailto:python-ideas-bounces+microcore=yahoo.com.cn@python.org] 代表 python-ideas-request@python.org 发送时间: 2011年1月21日 1:52 收件人: python-ideas@python.org 主题: Python-ideas Digest, Vol 50, Issue 34 Send Python-ideas mailing list submissions to python-ideas@python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/python-ideas or, via email, send a message with subject or body 'help' to python-ideas-request@python.org You can reach the person managing the list at python-ideas-owner@python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-ideas digest..." Today's Topics: 1. Re: A sorted version of **kwargs (Nick Coghlan) 2. Re: A sorted version of **kwargs (M.-A. Lemburg) 3. Re: A sorted version of **kwargs (Guido van Rossum) 4. Re: A sorted version of **kwargs (Imri Goldberg) 5. Re: A sorted version of **kwargs (geremy condra) ---------------------------------------------------------------------- Message: 1 Date: Thu, 20 Jan 2011 23:11:57 +1000 From: Nick Coghlan <ncoghlan@gmail.com> To: "Steven D'Aprano" <steve@pearwood.info> Cc: python-ideas@python.org Subject: Re: [Python-ideas] A sorted version of **kwargs Message-ID: <AANLkTik5XECCCBcgVvapyE4yEyCVAkN1-sFfaot+wbqE@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 20, 2011 at 8:28 PM, Steven D'Aprano <steve@pearwood.info> wrote:
I would be +0 on making **kwargs an ordered dict automatically, and -1 on adding ***ordered_kwargs. Because kwargs is mostly used only for argument passing, and generally with only a small number of items, it probably doesn't matter too much if it's slightly slower than an unordered dict.
Yeah, simply making the kwargs dict always ordered is likely the way we would do it. That's also the only solution with any chance of working by default with the way most decorators are structured (accepting *args and **kwargs and passing them to the wrapped function). To expand on Raymond's response in the previous thread on this topic, there are likely a number of steps to this process: 1. Provide a _collections.OrderedDict C implementation 2. Create a PEP to gain agreement from other implementations (especially IronPython, PyPy and Jython) to proceed with the remaining steps 3. Make it a builtin class (odict?) in its own right (with collections.OrderedDict becoming an alias for the builtin type) 4. Update the interpreter to use the new builtin type for kwargs containers Use various microbenchmarks to check that the use of the new odict builtin type instead of a plain dict doesn't slow things down too much. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan@gmail.com?? |?? Brisbane, Australia ------------------------------ Message: 2 Date: Thu, 20 Jan 2011 15:05:23 +0100 From: "M.-A. Lemburg" <mal@egenix.com> To: Nick Coghlan <ncoghlan@gmail.com> Cc: python-ideas@python.org Subject: Re: [Python-ideas] A sorted version of **kwargs Message-ID: <4D384123.6040105@egenix.com> Content-Type: text/plain; charset=ISO-8859-1 Nick Coghlan wrote:
On Thu, Jan 20, 2011 at 8:28 PM, Steven D'Aprano <steve@pearwood.info> wrote:
I would be +0 on making **kwargs an ordered dict automatically, and -1 on adding ***ordered_kwargs. Because kwargs is mostly used only for argument passing, and generally with only a small number of items, it probably doesn't matter too much if it's slightly slower than an unordered dict.
Yeah, simply making the kwargs dict always ordered is likely the way we would do it. That's also the only solution with any chance of working by default with the way most decorators are structured (accepting *args and **kwargs and passing them to the wrapped function).
-1. How often do you really need this ? In which of those cases wouldn't a static code analysis give you the call order of the parameters already ? "Nice to have" is not good enough to warrant a slow down of all function calls involving keyword arguments, adding overhead for other Python implementations and possibly causing problems with 3rd party extensions relying on getting a PyDict for the keyword arguments object. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 20 2011)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ------------------------------ Message: 3 Date: Thu, 20 Jan 2011 08:42:20 -0800 From: Guido van Rossum <guido@python.org> To: "M.-A. Lemburg" <mal@egenix.com> Cc: python-ideas@python.org Subject: Re: [Python-ideas] A sorted version of **kwargs Message-ID: <AANLkTimQmVdoR-hMc3Gq9Md+_w7bvra6uV1K2NjZaWoZ@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 20, 2011 at 6:05 AM, M.-A. Lemburg <mal@egenix.com> wrote:
Nick Coghlan wrote:
On Thu, Jan 20, 2011 at 8:28 PM, Steven D'Aprano <steve@pearwood.info> wrote:
I would be +0 on making **kwargs an ordered dict automatically, and -1 on adding ***ordered_kwargs. Because kwargs is mostly used only for argument passing, and generally with only a small number of items, it probably doesn't matter too much if it's slightly slower than an unordered dict.
Yeah, simply making the kwargs dict always ordered is likely the way we would do it. That's also the only solution with any chance of working by default with the way most decorators are structured (accepting *args and **kwargs and passing them to the wrapped function).
-1.
How often do you really need this ?
In which of those cases wouldn't a static code analysis give you the call order of the parameters already ??
"Nice to have" is not good enough to warrant a slow down of all function calls involving keyword arguments, adding overhead for other Python implementations and possibly causing problems with 3rd party extensions relying on getting a PyDict for the keyword arguments object.
What he says. In addition, I wonder what the semantics would be if the caller passed **d where d was an *unordered* dict... -- --Guido van Rossum (python.org/~guido) ------------------------------ Message: 4 Date: Thu, 20 Jan 2011 18:53:54 +0200 From: Imri Goldberg <lorgandon@gmail.com> To: Guido van Rossum <guido@python.org> Cc: python-ideas@python.org, "M.-A. Lemburg" <mal@egenix.com> Subject: Re: [Python-ideas] A sorted version of **kwargs Message-ID: <AANLkTin0GApx57hHQXpQLZ00wmqC_zY_xxzyW8vpRgtN@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" On Thu, Jan 20, 2011 at 6:42 PM, Guido van Rossum <guido@python.org> wrote:
-1.
How often do you really need this ?
In which of those cases wouldn't a static code analysis give you the call order of the parameters already ?
"Nice to have" is not good enough to warrant a slow down of all function calls involving keyword arguments, adding overhead for other Python implementations and possibly causing problems with 3rd party extensions relying on getting a PyDict for the keyword arguments object.
What he says.
In addition, I wonder what the semantics would be if the caller passed **d where d was an *unordered* dict...
What if the default behavior stays as it is today, but a magic decorator is added, (maybe @ordered_kwargs or some such), and only for these kind of functions the new behavior applies. Also, given such a decorator, when given **d where d is a regular dict, the implementation could possibly throw an error. (Or maybe it is up to the implementor of the specific function). Cheers, Imri -- Imri Goldberg -------------------------------------- http://plnnr.com/ - automatic trip planning http://www.algorithm.co.il/blogs/ -------------------------------------- -- insert signature here ----