On 05/14/2010 06:39 AM, Daniel Urban wrote:
I've made a new patch, in which the keywords attribute is a read-only
proxy of the dictionary.
What about backward compatibility? This looks like an incompatible change.
___
Python-Dev mailing list
On Mon, May 17, 2010 at 09:47, Hrvoje Niksic hrvoje.nik...@avl.com wrote:
On 05/14/2010 06:39 AM, Daniel Urban wrote:
I've made a new patch, in which the keywords attribute is a read-only
proxy of the dictionary.
What about backward compatibility? This looks like an incompatible change.
On Thu, May 13, 2010 at 13:30, Steven D'Aprano st...@pearwood.info wrote:
I'd support an immutable dict. partial objects already impose a
significant (~ 30%) performance penalty:
from timeit import Timer
min(Timer('f(5)', 'f = lambda x: x').repeat())
0.93580079078674316
min(Timer('p(5)',
I'm never certain where to reply in such a case, on the list or on the
issue, but since no one is nosy yet to Daniel's patch, I thought I'd ask
here.
While a partial object should reasonably never change, you could change it:
from functools import partial
p = partial(lambda *a, **kw: kw, 1, 2,
On Thu, 13 May 2010 06:50:02 pm Yaniv Aknin wrote:
I'm never certain where to reply in such a case, on the list or on
the issue, but since no one is nosy yet to Daniel's patch, I thought
I'd ask here.
While a partial object should reasonably never change, you could
change it:
[...]
I
While a partial object should reasonably never change, you could change it:
from functools import partial
p = partial(lambda *a, **kw: kw, 1, 2, spam='eggs')
p()
{'spam': 'eggs'}
p.keywords['spam'] = 'bacon'
p()
{'spam': 'bacon'}
I realize touching p.keywords voids your warranty, but if
I wrote an e-mail yesterday, but it seems, it didn't reach python-dev.
Here it is again:
On Thu, May 13, 2010 at 13:30, Steven D'Aprano st...@pearwood.info wrote:
I'd support an immutable dict. partial objects already impose a
significant (~ 30%) performance penalty:
from timeit import Timer
On 05/08/10 03:57, Steve Holden wrote:
Steven D'Aprano wrote:
[...]
Similarly, if you wanted p1==p2, why not write
p1 = partial(operator.add)
p2 = p1
I thought the OP gave a use-case. He's generating jobs (partial
applied to a callable and arguments), and wanted to avoid
Lie Ryan writes:
it disappoints me this does not compare equal:
add3 = lambda a, b, c: a + b + c
a = partial(partial(add3, 1), 2)
b = partial(partial(add3, 2), 1)
print a == b
:-)
But it's not even true for floating point.wink
___
On Wed, 12 May 2010 06:34:50 pm Stephen J. Turnbull wrote:
Lie Ryan writes:
it disappoints me this does not compare equal:
add3 = lambda a, b, c: a + b + c
a = partial(partial(add3, 1), 2)
b = partial(partial(add3, 2), 1)
print a == b
:-)
But it's not even true for
On 5/11/2010 11:54 PM, Cameron Simpson wrote:
I know for functions == and is currently are equivalent, but we should be
really finicky here about intent, especially since a few messages in the
thread is contemplate testing function for equivalence to one degree or
other. At which point == and
On Fri, May 7, 2010 at 17:02, Antoine Pitrou solip...@pitrou.net wrote:
It would be more useful to provide equality, hashing and repr to partial
itself,
rather than a subclass. Feel free to propose a patch :)
Hi!
I've done that.
I've opened a feature request: http://bugs.python.org/issue8699
On 07May2010 14:53, VanL van.lindb...@gmail.com wrote:
| On 5/7/2010 12:41 PM, Steven D'Aprano wrote:
| Now, if I write
|
| def f1(x,y): return x+y
| def f2(x,y): return x+y
|
| I don't expect f1==f2 to be True, even though f1 and f2 behave in
| exactly the same way, and indeed it
Howdy all -
I have an app where I am using functools.partial to bundle up jobs to
do, where a job is defined as a callable + args. In one case, I wanted
to keep track of whether I had previously seen a job, so I started
putting them into a set... only to find out that partials never test
equal to
On 07/05/2010 16:37, VanL wrote:
Howdy all -
I have an app where I am using functools.partial to bundle up jobs to
do, where a job is defined as a callable + args. In one case, I wanted
to keep track of whether I had previously seen a job, so I started
putting them into a set... only to find
VanL van.lindberg at gmail.com writes:
I created a subclass of functools.partial that provides appropriate
__eq__ and __hash__ methods, so that this works as expected. I called
the subclass a Job:
[...]
While I was at it, I also added a nice repr. Would this group be
interested in a
...@gmail.com
To: python-dev@python.org
Sent: Friday, May 07, 2010 3:37 PM
Subject: [Python-Dev] Possible patch for functools partial - Interested?
Howdy all -
I have an app where I am using functools.partial to bundle up jobs to
do, where a job is defined as a callable + args. In one case, I
On Sat, 8 May 2010 03:57:06 am Steve Holden wrote:
Steven D'Aprano wrote:
On Sat, 8 May 2010 02:07:55 am Rob Cliffe wrote:
Sorry to grouse, but isn't this maybe being a bit too clever?
Using your example,
p1 = partial(operator.add)
is creating a callable, p1, i.e. a sort of
On 5/7/2010 12:41 PM, Steven D'Aprano wrote:
Now, if I write
def f1(x,y): return x+y
def f2(x,y): return x+y
I don't expect f1==f2 to be True, even though f1 and f2 behave in
exactly the same way, and indeed it is not.
This is not what I am getting after; these (IMO) should
On Fri, 7 May 2010, VanL wrote:
I make no effort to look for functional equality between two different
functions. too many side effects could go off trying to make that work,
and it would still be only inconsistently right. (IIRC, doing it
completely is NP-hard.)
Actually, doing it completely
There is obviously interest in your proposal. I suggest you open an
issue on the tracker. Make it a library feature request for 3.2. Upload
the patch as a separate file. I would include the subclass form in the
post to show the intneded effect, for discussion, and also so people can
test and
21 matches
Mail list logo
