Introspecting add_to, undecorated, would have a __name__ of 'add_to' and __doc__ of 'Adds stuff'.
After decorating, add_to.__name__ becomes 'wrap' and __doc__ becomes None.
================
In Python 2.5+, there's functools.wraps, which takes care of the problem of introspection on decorated functions by copying attributes from the wrapped function.
Since Django already includes curry, which is roughly the same as functools.partial, it'd be pretty easy to back-port "wraps" to Django.
Is there any interest in a patch that modifies Django's built-in decorators to use functools.wraps in order to preserve things like view function doc strings?
....While I'm at it, I think aliasing functools.partial to functional.curry would be good, assuming functools is available.
> Since Django already includes curry, which is roughly the same as > functools.partial, it'd be pretty easy to back-port "wraps" to Django.
> Is there any interest in a patch that modifies Django's built-in > decorators to use functools.wraps in order to preserve things like > view function doc strings?
I love functools.wraps, but I never considered back-porting it in pure Python like curry. I'd personally love to see this happen, and I'd be glad to help out if you need it.
OT: I hope nobody uses this as an opportunity to complain about the naming of "curry". There was some discussion pre-2.5 about the difference between functools.partial and a true curry, but I don't think it's not worth making that distinction now.
On Thu, 2007-10-04 at 15:15 -0500, Jeremy Dunck wrote:
[...]
> Is there any interest in a patch that modifies Django's built-in > decorators to use functools.wraps in order to preserve things like > view function doc strings?
Definitely interest from me. It's a bit of a bug at the moment that we lose docstrings when we decorate things. Particular admin-docs loses stuff.
So, yeah, go for it.
> ....While I'm at it, I think aliasing functools.partial to > functional.curry would be good, assuming functools is available.
Providing the functionality is identical. Otherwise it's really, really painful to work out why things are behaving differently. We don't appear to be dramatically missing anything in our current currying stuff, so if this change would introduce different behaviour between 2.3 and, say, 2.5, I'd be against it.
On 10/4/07, Malcolm Tredinnick <malc...@pointy-stick.com> wrote:
> > ....While I'm at it, I think aliasing functools.partial to > > functional.curry would be good, assuming functools is available.
> Providing the functionality is identical. Otherwise it's really, really > painful to work out why things are behaving differently. We don't appear > to be dramatically missing anything in our current currying stuff, so if > this change would introduce different behaviour between 2.3 and, say, > 2.5, I'd be against it.
For some reason, I seem to recall there was some difference in how partial handles duplicate keyword arguments in the final call, as opposed to how curry does it. But when I actually do a side-by-side now, I can't discover any differences. So either I haven't figured out what I was doing before, or I was just smoking something at the time.
On 10/4/07, Malcolm Tredinnick <malc...@pointy-stick.com> wrote:
> On Thu, 2007-10-04 at 15:15 -0500, Jeremy Dunck wrote: > [...] > > Is there any interest in a patch that modifies Django's built-in > > decorators to use functools.wraps in order to preserve things like > > view function doc strings?
> Definitely interest from me. It's a bit of a bug at the moment that we > lose docstrings when we decorate things. Particular admin-docs loses > stuff.
> > ....While I'm at it, I think aliasing functools.partial to > > functional.curry would be good, assuming functools is available.
> Providing the functionality is identical. Otherwise it's really, really > painful to work out why things are behaving differently. We don't appear > to be dramatically missing anything in our current currying stuff, so if > this change would introduce different behaviour between 2.3 and, say, > 2.5, I'd be against it.
As far as I'm aware, the semantics are the same.
But on closer inspection, functools.partial actually returns a new type rather than a simple function. Things like inspect.getargspec fail on the result from functools.partial. With that in mind, I'll leave it out.
On 10/4/07, Jeremy Dunck <jdu...@gmail.com> wrote:
> On 10/4/07, Malcolm Tredinnick <malc...@pointy-stick.com> wrote:
> > On Thu, 2007-10-04 at 15:15 -0500, Jeremy Dunck wrote: > > [...] > > > Is there any interest in a patch that modifies Django's built-in > > > decorators to use functools.wraps in order to preserve things like > > > view function doc strings?
> > Definitely interest from me. It's a bit of a bug at the moment that we > > lose docstrings when we decorate things. Particular admin-docs loses > > stuff.
So, I've found a couple decorators I never knew existed. :)
Is there a reason django.views.http.require_http_method and friends aren't documented?
On 10/4/07, Malcolm Tredinnick <malc...@pointy-stick.com> wrote:
> On Thu, 2007-10-04 at 15:15 -0500, Jeremy Dunck wrote: > [...] > > Is there any interest in a patch that modifies Django's built-in > > decorators to use functools.wraps in order to preserve things like > > view function doc strings?
> Definitely interest from me. It's a bit of a bug at the moment that we > lose docstrings when we decorate things. Particular admin-docs loses > stuff.
On 10/7/07, Jeremy Dunck <jdu...@gmail.com> wrote:
> I note that this is a (perhaps subtle-enough) backwards-incompatible change.
Can you say a bit more about how this is backwards-incompatible? I'm having a dense morning, and can't seem to see any breakage here (which is a good thing!)
IANAL, but I think the Python Software License is not compatible with the BSD, so we'll need permission from the PSF to distribute code copied from functools.py, and we'll need to include the original copyright statement.
I notice as I write this that we only sorta followed this approach in the other bits from Python (_threading_local and _decimal). That really needs to be fixed. Grumble.
On Mon, Oct 08, 2007 at 10:49:14AM -0500, Jacob Kaplan-Moss wrote: > On 10/7/07, Jeremy Dunck <jdu...@gmail.com> wrote: > > I note that this is a (perhaps subtle-enough) backwards-incompatible change.
> Can you say a bit more about how this is backwards-incompatible? I'm > having a dense morning, and can't seem to see any breakage here (which > is a good thing!)
I think Jeremy was simply pointing out that object attributes are being permanently changed and somebody, somewhere may be relying on them currently. In this particular case that seems unlikely, of course.
On 10/8/07, Jacob Kaplan-Moss <jacob.kaplanm...@gmail.com> wrote:
> On 10/7/07, Jeremy Dunck <jdu...@gmail.com> wrote: > > I note that this is a (perhaps subtle-enough) backwards-incompatible change.
> Can you say a bit more about how this is backwards-incompatible? I'm > having a dense morning, and can't seem to see any breakage here (which > is a good thing!)
I just mean that current code doing naive introspection is getting decorator names rather than decorated names, and going forward it'll get the decorated name, etc.
That's the intent, but it is a change to existing (undocumented) functionality.
