Opened 10 years ago

Closed 6 years ago

#10479 closed Uncategorized (wontfix)

Use funtools.partial instead of django.utils.functional.curry

Reported by: Sebastian Noack Owned by: nobody
Component: Uncategorized Version: 1.0
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Django's curry method is just an implementation of Python 2.5's (and above) partial class from the functools module. But because of functools.partial is implemented as C extension, it is way faster than django's implementation.

# python2.5 -m timeit -s 'from django.utils.functional import curry; f = curry(lambda x: x, "foo")' 'f()'
100000 loops, best of 3: 2.27 usec per loop
# python2.5 -m timeit -s 'from functools import partial; f = partial(lambda x: x, "foo")' 'f()'
1000000 loops, best of 3: 0.417 usec per loop

So, is there a reason for not using partial instead of curry on Python2.5 and above? We could introduce a funccompat module and use it the same way as the itercompat module for example.

Change History (6)

comment:1 Changed 10 years ago by Jacob

Resolution: wontfix
Status: newclosed

curry and partial do have slightly different binding semantics (mostly because curry was written far before partial made its way into the stdlib. And I really doubt that in an actual application the difference is noticeable: a difference of 1.5 seconds over a million calls is peanuts in real life. Thus, I can't see a pragmatic reason to make this change.

comment:2 Changed 10 years ago by Sebastian Noack

Resolution: wontfix
Status: closedreopened

Can you explain more about the differences? I know that the implementation is an other, while partial returns a callable instance curry returns a function and since partial is implemented in C, it does not have some attributes as module for example. But if you need them you can just do wraps(func)(partial(func, *args, kwargs)).

How much this affects the performance of your django driven application depends on how much you are using curried functions. Many fields add curried functions as method to the model. But this ticket isn't only about performance. It is also about why re-implementing something which is also there in python? Well, you might say, we need this implementation anyway for python 2.4 and before. But look at how wraps and the functions from itercompat are used in django? I think this way would be more straight forward.

comment:3 Changed 10 years ago by Jacob

Resolution: wontfix
Status: reopenedclosed

Please don't reopen tickets closed by a committer. The correct way to revisit issues is to take it up on django-dev. Remember if you do to be concrete: why is this change important? What real-world problem do you have that this would solve?

comment:4 Changed 10 years ago by Sebastian Noack

I am sorry. I am used to reopen tickets in such cases. Btw, I don't think that this is an important issue. It was rather a small improvement proposal.

comment:5 Changed 6 years ago by anonymous

Easy pickings: unset
Resolution: wontfix
Severity: Normal
Status: closednew
Type: Uncategorized
UI/UX: unset

comment:6 Changed 6 years ago by Simon Charette

Resolution: wontfix
Status: newclosed

Please don't re-open tickets closed by a core developer 4 years ago with no apparent reason.

If you'd like to revisit this proposition take it up on django-dev as mentioned by jacob above.

Note: See TracTickets for help on using tickets.
Back to Top