[Python-ideas] A sorted version of **kwargs
陈宏葆
microcore at yahoo.com.cn
Fri Jan 21 03:28:23 CET 2011
Hi,
By the way, a sorted **kwargs may slow down the speed of function invocation.
But we do not know how often the function gets called.
So we mustn't enforce the dict to be sorted for it unpredictable defects in
performance. I need to emphasize the UNPREDICTABLE.
Hongbao Chen
Software Engineering School
Xi'an Jiaotong University
Cell:+8613891979195
________________________________
发件人： "python-ideas-request at python.org" <python-ideas-request at python.org>
收件人： python-ideas at python.org
发送日期： 2011/1/21 (周五) 9:59:06 上午
主 题： Python-ideas Digest, Vol 50, Issue 36
Send Python-ideas mailing list submissions to
python-ideas at 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 at python.org
You can reach the person managing the list at
python-ideas-owner at 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 (Don Spaulding)
2. Re: A sorted version of **kwargs (MRAB)
3. Re: A sorted version of **kwargs (Alexander Belopolsky)
4. Re: A sorted version of **kwargs (Nick Coghlan)
5. Re: A sorted version of **kwargs (Hongbao Chen)
----------------------------------------------------------------------
Message: 1
Date: Thu, 20 Jan 2011 14:26:23 -0600
From: Don Spaulding <donspauldingii at gmail.com>
To: Bruce Leban <bruce at leapyear.org>
Cc: python-ideas at python.org
Subject: Re: [Python-ideas] A sorted version of **kwargs
Message-ID:
<AANLkTinvh22idu-PTNOEF=qu9njK4uBmxpc5LJ7CXW_6 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Thu, Jan 20, 2011 at 2:05 PM, Bruce Leban <bruce at leapyear.org> wrote:
>
> On Thu, Jan 20, 2011 at 11:47 AM, Tim Delaney <timothy.c.delaney at gmail.com
> > wrote:
>
>>
>> ['b':1] would then be ambiguous (appears to be a slice of a list). More
>> obvious in the case of [1:2] ...
>>
>
> We use parenthesis for tuples and avoid the ambiguity by writing (1,).
> In the same way, we could require your examples to be written ['b':1,] and
> [1:2,]
>
Please, not this. I like the idea of syntactic support for the odict, but
no need to spread the (foo,) syntax around. It's too easy to misinterpret
when you do a quick scan of a body of code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.python.org/pipermail/python-ideas/attachments/20110120/52185887/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 20 Jan 2011 20:28:41 +0000
From: MRAB <python at mrabarnett.plus.com>
To: python-ideas <python-ideas at python.org>
Subject: Re: [Python-ideas] A sorted version of **kwargs
Message-ID: <4D389AF9.5080608 at mrabarnett.plus.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 20/01/2011 19:47, Tim Delaney wrote:
> On 21 January 2011 06:13, Bruce Leban <bruce at leapyear.org
> <mailto:bruce at leapyear.org>> wrote:
>
> Back to the original problem though: if the issue is that creating
> an ordered dict is clumsy and perhaps interfering with adoption and
> usage then perhaps the notation for ordered dict could be improved.
> Just as we can now use {...} for both dicts and sets, perhaps we
> could add
>
> [ 'b' : 1, 'a' : 2 ]
>
> as a more convenient way of writing
>
> OrderedDict([('b', 1), ('a', 2)])
>
>
> This is parallel to the way that [1,2] is an ordered container while
> {1,2} is unordered.
>
>
> ['b':1] would then be ambiguous (appears to be a slice of a list). More
> obvious in the case of [1:2] ...
>
[snip]
In what way is it ambiguous? [1] isn't ambiguous, is it?
spam[1] is subscripting and [1] is a list; spam[1 : 2] is slicing and
[1 : 2] would be an ordered dict.
------------------------------
Message: 3
Date: Thu, 20 Jan 2011 15:57:34 -0500
From: Alexander Belopolsky <alexander.belopolsky at gmail.com>
To: Tim Delaney <timothy.c.delaney at gmail.com>
Cc: python-ideas at python.org
Subject: Re: [Python-ideas] A sorted version of **kwargs
Message-ID:
<AANLkTik=n8+hJF34o9ME-iQ2q=kKXfG=ePmKboTWUyLh at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Jan 20, 2011 at 2:47 PM, Tim Delaney
<timothy.c.delaney at gmail.com> wrote:
..
> ['b':1] would then be ambiguous (appears to be a slice of a list). More
> obvious in the case of?[1:2] ...
x[1:2], x[1:2,], and x[1:2, 3:4] are all valid syntaxes. (NumPy uses
the latter for multi-dimensional slicing.) However, I don't see an
ambiguity here. We don't have an ambiguity between tuple syntax and
function calls: (a, b, c) vs. f(a, b, c).
------------------------------
Message: 4
Date: Fri, 21 Jan 2011 10:54:23 +1000
From: Nick Coghlan <ncoghlan at gmail.com>
To: Guido van Rossum <guido at python.org>
Cc: python-ideas at python.org, "M.-A. Lemburg" <mal at egenix.com>
Subject: Re: [Python-ideas] A sorted version of **kwargs
Message-ID:
<AANLkTikj1b4q1KUfRoPaYwqpUdE=pZDAzTaewftK6y4k at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Jan 21, 2011 at 2:42 AM, Guido van Rossum <guido at python.org> wrote:
> On Thu, Jan 20, 2011 at 6:05 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>> Nick Coghlan wrote:
>>> 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.
I actually agree as well, but I was misremembering how the
construction of the kwargs dict worked and hence was thinking that was
the only possible way this could work (since the interpreter didn't
know anything about the target function while building the dict).
Actually checking with dis.dis and looking at the associated code in
ceval.c corrected my misapprehension (the function is actually
retrieved first, while the kwargs are still on the stack in the
appropriate order, so it is theoretically possible for the function to
influence how the args are stored).
So, as an alternative proposal, perhaps it would be possible to add a
new protocol that allowed a callable to flag that an ordered
dictionary should be used for kwargs (e.g. an "__ordered_call__"
boolean attribute, with C level flags to speed up the common builtin
callable cases). A @functools.ordered_call decorator could then just
do "__ordered_call__ = True" to set the flag appropriately. (You could
also be even more flexible and devise a protocol that supported any
type for kwargs, but I think that would just be far more complicated
without a corresponding increase in expressive power)
Ordinary calls that used "x=y" or "**d" would be slowed down
marginally due to the check for the new attribute on the supplied
callable, but that impact should be minimal (especially for the
builtin cases, which would just be checking a C struct field) and
other calls would be entirely unaffected.
The CPython specific impact would largely be limited to
update_keyword_args() and implementing C level fields with associated
__ordered_call__ properties on the various builtin callable objects.
There would also need to be a new variant of PyEval_EvalCodeEx that
either used an ordered dictionary for kwdict, or else allowed kwdict
to be created and passed in by the calling code rather than implicitly
created via PyDict_New().
A builtin version of collections.OrderedDict would still be a
precursor to this idea though, so creating a _collections.OrderedDict
C implementation still sounds like the right starting point for anyone
that is particularly keen to see this idea progress.
Regards,
Nick.
--
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia
------------------------------
Message: 5
Date: Fri, 21 Jan 2011 09:58:41 +0800
From: "Hongbao Chen" <microcore at yahoo.com.cn>
To: <python-ideas at python.org>
Subject: Re: [Python-ideas] A sorted version of **kwargs
Message-ID:
<!&!AAAAAAAAAAAYAAAAAAAAAGTr5rf+rD9NmLF+0ao+1iuCggAAEAAAACvf3qXB2YNJuWd/o1VjxysBAAAAAA==@yahoo.com.cn>
Content-Type: text/plain; charset="gb2312"
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 at python.org
[mailto:python-ideas-bounces+microcore=yahoo.com.cn at python.org] ??
python-ideas-request at python.org
????: 2011?1?21? 1:52
???: python-ideas at python.org
??: Python-ideas Digest, Vol 50, Issue 34
Send Python-ideas mailing list submissions to
python-ideas at 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 at python.org
You can reach the person managing the list at
python-ideas-owner at 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 at gmail.com>
To: "Steven D'Aprano" <steve at pearwood.info>
Cc: python-ideas at python.org
Subject: Re: [Python-ideas] A sorted version of **kwargs
Message-ID:
<AANLkTik5XECCCBcgVvapyE4yEyCVAkN1-sFfaot+wbqE at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Jan 20, 2011 at 8:28 PM, Steven D'Aprano <steve at 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 at gmail.com?? |?? Brisbane, Australia
------------------------------
Message: 2
Date: Thu, 20 Jan 2011 15:05:23 +0100
From: "M.-A. Lemburg" <mal at egenix.com>
To: Nick Coghlan <ncoghlan at gmail.com>
Cc: python-ideas at python.org
Subject: Re: [Python-ideas] A sorted version of **kwargs
Message-ID: <4D384123.6040105 at 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 at 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 at python.org>
To: "M.-A. Lemburg" <mal at egenix.com>
Cc: python-ideas at python.org
Subject: Re: [Python-ideas] A sorted version of **kwargs
Message-ID:
<AANLkTimQmVdoR-hMc3Gq9Md+_w7bvra6uV1K2NjZaWoZ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Jan 20, 2011 at 6:05 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> Nick Coghlan wrote:
>> On Thu, Jan 20, 2011 at 8:28 PM, Steven D'Aprano <steve at 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 at gmail.com>
To: Guido van Rossum <guido at python.org>
Cc: python-ideas at python.org, "M.-A. Lemburg" <mal at egenix.com>
Subject: Re: [Python-ideas] A sorted version of **kwargs
Message-ID:
<AANLkTin0GApx57hHQXpQLZ00wmqC_zY_xxzyW8vpRgtN at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Thu, Jan 20, 2011 at 6:42 PM, Guido van Rossum <guido at 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 ----
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.python.org/pipermail/python-ideas/attachments/20110120/0bf7be8a
/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 20 Jan 2011 09:52:21 -0800
From: geremy condra <debatem1 at gmail.com>
To: Guido van Rossum <guido at python.org>
Cc: python-ideas at python.org, "M.-A. Lemburg" <mal at egenix.com>
Subject: Re: [Python-ideas] A sorted version of **kwargs
Message-ID:
<AANLkTiky7RDpJzxfmBLvVSTFQdj0P1-D9Bs8wn4RH0G3 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Jan 20, 2011 at 8:42 AM, Guido van Rossum <guido at python.org> wrote:
> On Thu, Jan 20, 2011 at 6:05 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>> Nick Coghlan wrote:
>>> On Thu, Jan 20, 2011 at 8:28 PM, Steven D'Aprano <steve at 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...
Wouldn't this be a good argument for the original proposal? That there
wouldn't be confusion about whether you were getting an odict or a
dict with ***?
Also, would functions that didn't specify this behavior see an actual
performance hit? I assumed that given the existence of METH_NOARGS and
friends that there was some kind of optimization going on here, but I
can't get it to turn up on timeit.
Geremy Condra
------------------------------
_______________________________________________
Python-ideas mailing list
Python-ideas at python.org
http://mail.python.org/mailman/listinfo/python-ideas
End of Python-ideas Digest, Vol 50, Issue 34
********************************************
__________________________________________________
???????????????
http://cn.mail.yahoo.com
------------------------------
_______________________________________________
Python-ideas mailing list
Python-ideas at python.org
http://mail.python.org/mailman/listinfo/python-ideas
End of Python-ideas Digest, Vol 50, Issue 36
********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110121/ca8830e3/attachment.html>
More information about the Python-ideas
mailing list