Re: [Python-Dev] decorator module in stdlib?
Guido van Rossum wrote: On Wed, Apr 8, 2009 at 9:31 PM, Michele Simionato michele.simion...@gmail.com wrote: Then perhaps you misunderstand the goal of the decorator module. The raison d'etre of the module is to PRESERVE the signature: update_wrapper unfortunately *changes* it. When confronted with a library which I do not not know, I often run over it pydoc, or sphinx, or a custom made documentation tool, to extract the signature of functions. Ah, I see. Personally I rarely trust automatically extracted documentation -- too often in my experience it is out of date or simply absent. Extracting the signatures in theory wouldn't lie, but in practice I still wouldn't trust it -- not only because of what decorators might or might not do, but because it might still be misleading. Call me old-fashioned, but I prefer to read the source code. If you auto-generate API documentation by introspection (which we do at Resolver Systems) then preserving signatures can also be important. Interactive use (support for help), and more straightforward tracebacks in the event of usage errors are other reasons to want to preserve signatures and function name. For instance, if I see a method get_user(self, username) I have a good hint about what it is supposed to do. But if the library (say a web framework) uses non signature-preserving decorators, my documentation tool says to me that there is function get_user(*args, **kwargs) which frankly is not enough [this is the optimistic case, when the author of the decorator has taken care to preserve the name of the original function]. But seeing the decorator is often essential for understanding what goes on! Even if the decorator preserves the signature (in truth or according inspect), many decorators *do* something, and it's important to know how a function is decorated. For example, I work a lot with a small internal framework at Google whose decorators can raise exceptions and set instance variables; they also help me understand under which conditions a method can be called. Having methods renamed to 'wrapped' and their signature changed to *args, **kwargs may tell you there *is* a decorator but doesn't give you any useful information about what it does. If you look at the code then the decorator is obvious (whether or not it mangles the method)... [+1] But I feel strongly about the possibility of being able to preserve (not change!) the function signature. That could be added to functools if enough people want it. +1 Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
Guido van Rossum wrote: On Wed, Apr 8, 2009 at 9:31 PM, Michele Simionato But I feel strongly about the possibility of being able to preserve (not change!) the function signature. That could be added to functools if enough people want it. No objection in principle here - it's just hard to do cleanly without PEP 362's __signature__ attribute to underpin it. Without that as a basis, I expect you'd end up being forced to do something similar to what Michele does in the decorator module - inspect the function being wrapped and then use exec to generate a wrapper with a matching signature. Another nice introspection enhancement might be to give class and function objects writable __file__ and __line__ attributes (initially set appropriately by the compiler) and have the inspect modules use those when they're available. Then functools.update_wrapper() could be adjusted to copy those attributes, meaning that the wrapper function would point back to the original (decorated) function for the source code, rather than to the definition of the wrapper (note that the actual wrapper code could still be found by looking at the metadata on the function's __code__ attribute). Unfortunately-ideas-aren't-working-code'ly, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
Michele Simionato wrote: On Wed, Apr 8, 2009 at 7:51 PM, Guido van Rossum gu...@python.org wrote: There was a remark (though perhaps meant humorously) in Michele's page about decorators that worried me too: For instance, typical implementations of decorators involve nested functions, and we all know that flat is better than nested. I find the nested-function pattern very clear and easy to grasp, whereas I find using another decorator (a meta-decorator?) to hide this pattern unnecessarily obscuring what's going on. I understand your point and I will freely admit that I have always had mixed feelings about the advantages of a meta decorator with respect to plain simple nested functions. I see pros and contras. If functools.update_wrapper could preserve the signature I would probably use it over the decorator module. Yep, update_wrapper was a compromise along the lines of well, at least we can make sure the relevant metadata refers to the original function rather than the relatively uninteresting wrapper, even if the signature itself is lost. The idea being that you can often figure out the signature from the doc string even when introspection has been broken by an intervening wrapper. One of my hopes for PEP 362 was that I would be able to just add __signature__ to the list of copied attributes, but that PEP is currently short a champion to work through the process of resolving the open issues and creating an up to date patch (Brett ended up with too many things on his plate so he wasn't able to do it, and nobody else has offered to take it over). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
On Thu, Apr 9, 2009 at 2:11 PM, Nick Coghlan ncogh...@gmail.com wrote: One of my hopes for PEP 362 was that I would be able to just add __signature__ to the list of copied attributes, but that PEP is currently short a champion to work through the process of resolving the open issues and creating an up to date patch (Brett ended up with too many things on his plate so he wasn't able to do it, and nobody else has offered to take it over). I am totally ignorant about the internals of Python and I cannot certainly take that role. But I would like to hear from Guido if he wants to support a __signature__ object or if he does not care. In the first case I think somebody will take the job, in the second case it is better to reject the PEP and be done with it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
Michele Simionato wrote: On Thu, Apr 9, 2009 at 2:11 PM, Nick Coghlan ncogh...@gmail.com wrote: One of my hopes for PEP 362 was that I would be able to just add __signature__ to the list of copied attributes, but that PEP is currently short a champion to work through the process of resolving the open issues and creating an up to date patch (Brett ended up with too many things on his plate so he wasn't able to do it, and nobody else has offered to take it over). I am totally ignorant about the internals of Python and I cannot certainly take that role. But I would like to hear from Guido if he wants to support a __signature__ object or if he does not care. In the first case I think somebody will take the job, in the second case it is better to reject the PEP and be done with it. I don't recall Guido being opposed when PEP 362 was first being discussed (keeping in mind that was more than 2 years ago, so he's quite entitled to have changed his mind in the meantime!). That said, it's a sensible, largely straightforward idea, and by creating the object lazily it doesn't even have to incur a runtime cost in programs that don't do much introspection. I think the main problem leading to the current lack of movement on the PEP is that the existing inspect module is good enough for most practical purposes (which are fairly rare in the first place), so this isn't perceived as a huge gain even for the folks that are interested in introspection. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
On Wed, Apr 8, 2009 at 9:31 PM, Michele Simionato michele.simion...@gmail.com wrote: Then perhaps you misunderstand the goal of the decorator module. The raison d'etre of the module is to PRESERVE the signature: update_wrapper unfortunately *changes* it. When confronted with a library which I do not not know, I often run over it pydoc, or sphinx, or a custom made documentation tool, to extract the signature of functions. Ah, I see. Personally I rarely trust automatically extracted documentation -- too often in my experience it is out of date or simply absent. Extracting the signatures in theory wouldn't lie, but in practice I still wouldn't trust it -- not only because of what decorators might or might not do, but because it might still be misleading. Call me old-fashioned, but I prefer to read the source code. For instance, if I see a method get_user(self, username) I have a good hint about what it is supposed to do. But if the library (say a web framework) uses non signature-preserving decorators, my documentation tool says to me that there is function get_user(*args, **kwargs) which frankly is not enough [this is the optimistic case, when the author of the decorator has taken care to preserve the name of the original function]. But seeing the decorator is often essential for understanding what goes on! Even if the decorator preserves the signature (in truth or according inspect), many decorators *do* something, and it's important to know how a function is decorated. For example, I work a lot with a small internal framework at Google whose decorators can raise exceptions and set instance variables; they also help me understand under which conditions a method can be called. I *hate* losing information about the true signature of functions, since I also use a lot IPython, Python help, etc. I guess we just have different styles. That's fine. I must admit that while I still like decorators, I do like them as much as in the past. Of course there was a missing NOT in this sentence, but you all understood the intended meaning. (All this BTW is not to say that I don't trust you with commit privileges if you were to be interested in contributing. I just don't think that adding that particular decorator module to the stdlib would be wise. It can be debated though.) Fine. As I have repeated many time that particular module was never meant for inclusion in the standard library. Then perhaps it shouldn't -- I haven't looked but if you don't plan stdlib inclusion it is often the case that the API style and/or implementation details make stdlib inclusion unrealistic. (Though admittedly some older modules wouldn't be accepted by today's standards either -- and I'm not just talking PEP-8 compliance! :-) But I feel strongly about the possibility of being able to preserve (not change!) the function signature. That could be added to functools if enough people want it. I do not think everybody disagree with your point here. My point still stands, though: objects should not lie about their signature, especially during debugging and when generating documentation from code. Source code never lies. Debuggers should make access to the source code a key point. And good documentation should be written by a human, not automatically cobbled together from source code and a few doc strings. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
Then perhaps you misunderstand the goal of the decorator module. The raison d'etre of the module is to PRESERVE the signature: update_wrapper unfortunately *changes* it. When confronted with a library which I do not not know, I often run over it pydoc, or sphinx, or a custom made documentation tool, to extract the signature of functions. Ah, I see. Personally I rarely trust automatically extracted documentation -- too often in my experience it is out of date or simply absent. Extracting the signatures in theory wouldn't lie, but in practice I still wouldn't trust it -- not only because of what decorators might or might not do, but because it might still be misleading. Call me old-fashioned, but I prefer to read the source code. For instance, if I see a method get_user(self, username) I have a good hint about what it is supposed to do. But if the library (say a web framework) uses non signature-preserving decorators, my documentation tool says to me that there is function get_user(*args, **kwargs) which frankly is not enough [this is the optimistic case, when the author of the decorator has taken care to preserve the name of the original function]. But seeing the decorator is often essential for understanding what goes on! Even if the decorator preserves the signature (in truth or according inspect), many decorators *do* something, and it's important to know how a function is decorated. For example, I work a lot with a small internal framework at Google whose decorators can raise exceptions and set instance variables; they also help me understand under which conditions a method can be called. I *hate* losing information about the true signature of functions, since I also use a lot IPython, Python help, etc. I guess we just have different styles. That's fine. I must admit that while I still like decorators, I do like them as much as in the past. Of course there was a missing NOT in this sentence, but you all understood the intended meaning. (All this BTW is not to say that I don't trust you with commit privileges if you were to be interested in contributing. I just don't think that adding that particular decorator module to the stdlib would be wise. It can be debated though.) Fine. As I have repeated many time that particular module was never meant for inclusion in the standard library. Then perhaps it shouldn't -- I haven't looked but if you don't plan stdlib inclusion it is often the case that the API style and/or implementation details make stdlib inclusion unrealistic. (Though admittedly some older modules wouldn't be accepted by today's standards either -- and I'm not just talking PEP-8 compliance! :-) But I feel strongly about the possibility of being able to preserve (not change!) the function signature. That could be added to functools if enough people want it. My original suggestion for inclusion in stdlib was motivated by this reason alone: I'd like to see an official one way of preserving function signatures by decorators. If there are better ways of doing it than the decorator module, that's totally fine, but there should be one. Cheers, Daniel I do not think everybody disagree with your point here. My point still stands, though: objects should not lie about their signature, especially during debugging and when generating documentation from code. Source code never lies. Debuggers should make access to the source code a key point. And good documentation should be written by a human, not automatically cobbled together from source code and a few doc strings. -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
On Wed, Apr 8, 2009 at 12:09 AM, Michele Simionato michele.simion...@gmail.com wrote: On Tue, Apr 7, 2009 at 11:04 PM, Terry Reedy tjre...@udel.edu wrote: This probably should have gone to the python-ideas list. In any case, I think it needs to start with a clear offer from Michele (directly or relayed by you) to contribute it to the PSF with the usual conditions. I have no problem to contribute the module to the PSF and to maintain it. I would just prefer to have the ability to change the function signature in the core language rather than include in the standard library a clever hack. Flipping Michele's commit bit (if he wants it) is overdue. A quick google doesn't show he refused it in the past, but the same search shows the things things he did do - including the explication of MRO in 2.3 (http://www.python.org/download/releases/2.3/mro/). Plus he's a softie for decorators, as am I. -Jack ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
On Wed, Apr 8, 2009 at 8:10 AM, Jack diederich jackd...@gmail.com wrote: Plus he's a softie for decorators, as am I. I must admit that while I still like decorators, I do like them as much as in the past. I also see an overuse of decorators in various libraries for things that could be done more clearly without them ;-( But this is tangential. What I would really like to know is the future of PEP 362, i.e. having a signature object that could be taken from an undecorated function and added to the decorated function. I do not recall people having anything against it, in principle, and there is also an implementation in the sandbox, but after three years nothing happened. I guess this is just not a high priority for the core developers. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
On Wed, Apr 8, 2009 at 12:17 AM, Michele Simionato michele.simion...@gmail.com wrote: On Wed, Apr 8, 2009 at 8:10 AM, Jack diederich jackd...@gmail.com wrote: Plus he's a softie for decorators, as am I. This worries me a bit. There was a remark (though perhaps meant humorously) in Michele's page about decorators that worried me too: For instance, typical implementations of decorators involve nested functions, and we all know that flat is better than nested. I find the nested-function pattern very clear and easy to grasp, whereas I find using another decorator (a meta-decorator?) to hide this pattern unnecessarily obscuring what's going on. I also happen to disagree in many cases with decorators that attempt to change the signature of the wrapper function to that of the wrapped function. While this may make certain kinds of introspection possible, again it obscures what's going on to a future maintainer of the code, and the cleverness can get in the way of good old-fashioned debugging. I must admit that while I still like decorators, I do like them as much as in the past. I also see an overuse of decorators in various libraries for things that could be done more clearly without them ;-( Right. But this is tangential. (All this BTW is not to say that I don't trust you with commit privileges if you were to be interested in contributing. I just don't think that adding that particular decorator module to the stdlib would be wise. It can be debated though.) What I would really like to know is the future of PEP 362, i.e. having a signature object that could be taken from an undecorated function and added to the decorated function. I do not recall people having anything against it, in principle, and there is also an implementation in the sandbox, but after three years nothing happened. I guess this is just not a high priority for the core developers. That's likely true. To me, introspection is mostly useful for certain situations like debugging or interactively finding help, but I would hesitate to build a large amount of stuff (whether a library, framework or application) on systematic use of introspection. In fact, I rarely use the inspect module and had to type help(inspect) to figure out what you meant by signature. :-) I guess one reason is that in my mind, and in the way I tend to write code, I don't write APIs that require introspection -- for example, I don't like APIs that do different things when given a callable as opposed to something else (common practices in web frameworks notwithstanding), and thinking about it I would like it even less if an API cared about the *actual* signature of a function I pass into it. I like APIs that say, for example, argument 'f' must be a function of two arguments, an int and a string, and then I assume that if I pass it something for 'f' it will try to call that something with an int and a string. If I pass it something else, well, I'll get a type error. But it gives me the freedom to pass something that doesn't even have a signature but happens to be callable in that way regardless (e.g. a bound method of a built-in type). I will probably regret saying this. So be it. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
At 10:51 AM 4/8/2009 -0700, Guido van Rossum wrote: I would like it even less if an API cared about the *actual* signature of a function I pass into it. One notable use of callable argument inspection is Bobo, the 12-years-ago predecessor to Zope, which used argument information to determine form or query string parameter names. (Were Bobo being written for the first time today for Python 3, I imagine it would use argument annotations to specify types, instead of requiring them to be in the client-side field names.) Bobo, of course, is just a single case of the general pattern of tools that expose a callable to some other (possibly explicitly-typed) system. E.g., wrapping Python functions for exposure to C, Java, .NET, CORBA, SOAP, etc. Anyway, it's nice for decorators to be transparent to inspection when the decorator doesn't actually modify the calling signature, so that you can then use your decorated functions with tools like the above. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
P.J. Eby wrote: Anyway, it's nice for decorators to be transparent to inspection when the decorator doesn't actually modify the calling signature, so that you can then use your decorated functions with tools like the above. If anyone wanted to take PEP 362 up again, we could easily add a __signature__ attribute to functools.update_wrapper. It may be too late to hammer it into shape for 3.1/2.7 though (I don't recall how far the PEP was from being ready for prime time) . Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
On Wed, Apr 8, 2009 at 7:51 PM, Guido van Rossum gu...@python.org wrote: There was a remark (though perhaps meant humorously) in Michele's page about decorators that worried me too: For instance, typical implementations of decorators involve nested functions, and we all know that flat is better than nested. I find the nested-function pattern very clear and easy to grasp, whereas I find using another decorator (a meta-decorator?) to hide this pattern unnecessarily obscuring what's going on. I understand your point and I will freely admit that I have always had mixed feelings about the advantages of a meta decorator with respect to plain simple nested functions. I see pros and contras. If functools.update_wrapper could preserve the signature I would probably use it over the decorator module. I also happen to disagree in many cases with decorators that attempt to change the signature of the wrapper function to that of the wrapped function. While this may make certain kinds of introspection possible, again it obscures what's going on to a future maintainer of the code, and the cleverness can get in the way of good old-fashioned debugging. Then perhaps you misunderstand the goal of the decorator module. The raison d'etre of the module is to PRESERVE the signature: update_wrapper unfortunately *changes* it. When confronted with a library which I do not not know, I often run over it pydoc, or sphinx, or a custom made documentation tool, to extract the signature of functions. For instance, if I see a method get_user(self, username) I have a good hint about what it is supposed to do. But if the library (say a web framework) uses non signature-preserving decorators, my documentation tool says to me that there is function get_user(*args, **kwargs) which frankly is not enough [this is the optimistic case, when the author of the decorator has taken care to preserve the name of the original function]. I *hate* losing information about the true signature of functions, since I also use a lot IPython, Python help, etc. I must admit that while I still like decorators, I do like them as much as in the past. Of course there was a missing NOT in this sentence, but you all understood the intended meaning. (All this BTW is not to say that I don't trust you with commit privileges if you were to be interested in contributing. I just don't think that adding that particular decorator module to the stdlib would be wise. It can be debated though.) Fine. As I have repeated many time that particular module was never meant for inclusion in the standard library. But I feel strongly about the possibility of being able to preserve (not change!) the function signature. To me, introspection is mostly useful for certain situations like debugging or interactively finding help, but I would hesitate to build a large amount of stuff (whether a library, framework or application) on systematic use of introspection. In fact, I rarely use the inspect module and had to type help(inspect) to figure out what you meant by signature. :-) I guess one reason is that in my mind, and in the way I tend to write code, I don't write APIs that require introspection -- for example, I don't like APIs that do different things when given a callable as opposed to something else (common practices in web frameworks notwithstanding), and thinking about it I would like it even less if an API cared about the *actual* signature of a function I pass into it. I like APIs that say, for example, argument 'f' must be a function of two arguments, an int and a string, and then I assume that if I pass it something for 'f' it will try to call that something with an int and a string. If I pass it something else, well, I'll get a type error. But it gives me the freedom to pass something that doesn't even have a signature but happens to be callable in that way regardless (e.g. a bound method of a built-in type). I do not think everybody disagree with your point here. My point still stands, though: objects should not lie about their signature, especially during debugging and when generating documentation from code. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
Daniel Fetchinson wrote: The decorator module [1] written by Michele Simionato is a very useful tool for maintaining function signatures while applying a decorator. Many different projects implement their own versions of the same functionality, for example turbogears has its own utility for this, I guess others do something similar too. Was the issue whether to include this module in the stdlib raised? If yes, what were the arguments against it? If not, what do you folks think, shouldn't it be included? I certainly think it should be. Originally I sent this message to c.l.p [2] and Michele suggested it be brought up on python-dev. He also pointed out that a PEP [3] is already written about this topic and it is in draft form. What do you guys think, wouldn't this be a useful addition to functools? [1] http://pypi.python.org/pypi/decorator [2] http://groups.google.com/group/comp.lang.python/browse_thread/thread/d4056023f1150fe0 [3] http://www.python.org/dev/peps/pep-0362/ This probably should have gone to the python-ideas list. In any case, I think it needs to start with a clear offer from Michele (directly or relayed by you) to contribute it to the PSF with the usual conditions. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
On Tue, Apr 7, 2009 at 11:04 PM, Terry Reedy tjre...@udel.edu wrote: This probably should have gone to the python-ideas list. In any case, I think it needs to start with a clear offer from Michele (directly or relayed by you) to contribute it to the PSF with the usual conditions. I have no problem to contribute the module to the PSF and to maintain it. I would just prefer to have the ability to change the function signature in the core language rather than include in the standard library a clever hack. M. Simionato ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] decorator module in stdlib?
The decorator module [1] written by Michele Simionato is a very useful tool for maintaining function signatures while applying a decorator. Many different projects implement their own versions of the same functionality, for example turbogears has its own utility for this, I guess others do something similar too. Was the issue whether to include this module in the stdlib raised? If yes, what were the arguments against it? If not, what do you folks think, shouldn't it be included? I certainly think it should be. Originally I sent this message to c.l.p [2] and Michele suggested it be brought up on python-dev. He also pointed out that a PEP [3] is already written about this topic and it is in draft form. What do you guys think, wouldn't this be a useful addition to functools? Cheers, Daniel [1] http://pypi.python.org/pypi/decorator [2] http://groups.google.com/group/comp.lang.python/browse_thread/thread/d4056023f1150fe0 [3] http://www.python.org/dev/peps/pep-0362/ -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
