Code

Opened 5 years ago

Closed 12 months 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

Description

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.

Attachments (0)

Change History (6)

comment:1 Changed 5 years ago by jacob

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

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 5 years ago by sebastian_noack

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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 5 years ago by jacob

  • Resolution set to wontfix
  • Status changed from reopened to closed

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 5 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 12 months ago by anonymous

  • Easy pickings unset
  • Resolution wontfix deleted
  • Severity set to Normal
  • Status changed from closed to new
  • Type set to Uncategorized
  • UI/UX unset

comment:6 Changed 12 months ago by charettes

  • Resolution set to wontfix
  • Status changed from new to closed

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.