[Python-Dev] decorator module patch
Raymond Hettinger wrote: In contrast, a name like functional suggests that some of these tools don't quite fit. The original intent was that the functional module become the home of typical utilities for functional style programming. partial was there were patches (such as 1412451) providing quite a few additional tools and improved documentation on the more functional builtins (such as map and reduce). That particular patch was closed to spend time as an independent module first, but there is a fair chance that parts of it will eventually be added. (OTOH, it might be just a few parts which fit well under functools, rather tha just functional) -jJ ___ 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 patch
Hi, to underlay my proposals with facts, I've written a simple decorator module containing at the moment only the decorator decorator. http://python.org/sf/1448297 It is implemented as a C extension module _decorator which contains the decorator object (modelled after the functional.partial object) and a Lib/decorator.py to allow further decorators added as Python code. Comes with docs and unit test. Please review! Cheers, Georg ___ 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 patch
Georg Brandl wrote: Hi, to underlay my proposals with facts, I've written a simple decorator module containing at the moment only the decorator decorator. http://python.org/sf/1448297 It is implemented as a C extension module _decorator which contains the decorator object (modelled after the functional.partial object) and a Lib/decorator.py to allow further decorators added as Python code. Comes with docs and unit test. Given that @decorator is a definition time only operation to modify a function's __name__, __doc__ and __dict__ attributes, and doesn't actually introduce any extra levels of run-time nesting to function calls, I'm not clear on why you bothered with a hybrid implementation instead of sticking with pure Python. (To clarify what I mean: using the example in the doc patch, the extra layer of run-time nesting from @decorator's wrapper function applies only to the @logged decorator, not to the function 'print_nested'. If an application has a decorated function definition in a performance critical path, a little bit of extra overhead from @decorator is the least of its worries.) Also, I thought we were trying to move away from modules that shared a name with one of their public functions or classes. As it is, I'm not even sure that a name like decorator gives the right emphasis. In general, decorators belong in the appropriate domain-specific module (similar to context managers). In this case, though, the domain is the manipulation of Python functions - maybe the module should be called metafunctions or functools to reflect its application domain, rather than the coincidental fact that its first member happens to be a decorator. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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 patch
Nick Coghlan wrote: Georg Brandl wrote: Hi, to underlay my proposals with facts, I've written a simple decorator module containing at the moment only the decorator decorator. Sorry, I forgot the initial comment which was meant to be Thanks for moving this proposal forward :) It's currently all too easy to write decorators that don't play nicely with introspection. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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 patch
Nick Coghlan wrote: Georg Brandl wrote: Hi, to underlay my proposals with facts, I've written a simple decorator module containing at the moment only the decorator decorator. http://python.org/sf/1448297 It is implemented as a C extension module _decorator which contains the decorator object (modelled after the functional.partial object) and a Lib/decorator.py to allow further decorators added as Python code. Comes with docs and unit test. Given that @decorator is a definition time only operation to modify a function's __name__, __doc__ and __dict__ attributes, and doesn't actually introduce any extra levels of run-time nesting to function calls, I'm not clear on why you bothered with a hybrid implementation instead of sticking with pure Python. Good question... partly because I wanted to make myself more intimate with the C API and extension modules. Everyone can write that in Python... wink (To clarify what I mean: using the example in the doc patch, the extra layer of run-time nesting from @decorator's wrapper function applies only to the @logged decorator, not to the function 'print_nested'. If an application has a decorated function definition in a performance critical path, a little bit of extra overhead from @decorator is the least of its worries.) Right. I'm not opposed to a Python-only module, I've had my fun :) Also, I thought we were trying to move away from modules that shared a name with one of their public functions or classes. As it is, I'm not even sure that a name like decorator gives the right emphasis. I thought about decorators too, that would make decorators.decorator. Hm. In general, decorators belong in the appropriate domain-specific module (similar to context managers). In this case, though, the domain is the manipulation of Python functions - maybe the module should be called metafunctions or functools to reflect its application domain, rather than the coincidental fact that its first member happens to be a decorator. Depends on what else will end up there. If it's memoize or deprecated then the name functools doesn't sound too good either. Georg ___ 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 patch
Georg Brandl wrote: Also, I thought we were trying to move away from modules that shared a name with one of their public functions or classes. As it is, I'm not even sure that a name like decorator gives the right emphasis. I thought about decorators too, that would make decorators.decorator. Hm. I personally like pluralized modules for exactly the reason that they don't clash as much with members or likely local variables. datetime.datetime frequently leads me to make mistakes. In general, decorators belong in the appropriate domain-specific module (similar to context managers). In this case, though, the domain is the manipulation of Python functions - maybe the module should be called metafunctions or functools to reflect its application domain, rather than the coincidental fact that its first member happens to be a decorator. Depends on what else will end up there. If it's memoize or deprecated then the name functools doesn't sound too good either. memoize seems to fit into functools fairly well, though deprecated not so much. functools is similarly named to itertools, another module that is kind of vague in scope (though functools is much more vague). partial would make just as much sense in functools as in functional. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org ___ 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 patch
On Mar 12, 2006, at 11:16 AM, Ian Bicking wrote: ... memoize seems to fit into functools fairly well, though deprecated not so much. functools is similarly named to itertools, another module that is kind of vague in scope (though functools is much more vague). partial would make just as much sense in functools as in functional. Couldn't we merge functools and functional into just one (user- visible) module? The distinction between what goes into one vs the other is exceedingly subtle and poor users will be guessing as to what's where. If we need a mixed module with something in C and something in Python, we can do it the usual way, func.py wrapping _func.pyd (or .so or whatever)... Alex ___ 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 patch
[Ian Bicking] memoize seems to fit into functools fairly well, though deprecated not so much. functools is similarly named to itertools, another module that is kind of vague in scope (though functools is much more vague). partial would make just as much sense in functools as in functional. [Alex] Couldn't we merge functools and functional into just one (user- visible) module? The distinction between what goes into one vs the other is exceedingly subtle and poor users will be guessing as to what's where. If we need a mixed module with something in C and something in Python, we can do it the usual way, func.py wrapping _func.pyd (or .so or whatever)... +1 on putting the tools all in one module. With respect to decorator entries, I would like to see python-dev collectively decide to show restraint. There are so many ways to write and use decorators that best-of-the-best are not yet obvious. Hopefully, collections of decorators will be allowed to grow-in-the-wild as recipes and as third-party modules before being put into the core. Georg's proposal seems like a good candidate for a first entry -- its chief virtue being that it may help people avoid writing crummy decorators. If his goes in, hopefully it will not fall down a slippery slope and trigger an avalance of immature decorators being added to the core. my-two-cents, Raymond ___ 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 patch
Alex Martelli wrote: On Mar 12, 2006, at 11:16 AM, Ian Bicking wrote: ... memoize seems to fit into functools fairly well, though deprecated not so much. functools is similarly named to itertools, another module that is kind of vague in scope (though functools is much more vague). partial would make just as much sense in functools as in functional. Couldn't we merge functools and functional into just one (user- visible) module? The distinction between what goes into one vs the other is exceedingly subtle and poor users will be guessing as to what's where. If we need a mixed module with something in C and something in Python, we can do it the usual way, func.py wrapping _func.pyd (or .so or whatever)... I agree it makes sense to have decorator, memoize, deprecated and partial all being members of the same module, whether the name be functools or functional (although I have a slight preference for functools due to the parallel with itertools). On the question of whether or not deprecated fits in as a function tool, I know I'd tend to only use it on functions (to deprecate a class, I'd simply decorate the class's __init__ or __new__ method). Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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 patch
[Nick Coghlan] I agree it makes sense to have decorator, memoize, deprecated and partial all being members of the same module, whether the name be functools or functional (although I have a slight preference for functools due to the parallel with itertools). I like functools for a different reason -- the name is sufficiently broad so that we don't have fret about whether a particular tool fits within the module's scope. In contrast, a name like functional suggests that some of these tools don't quite fit. Raymond ___ 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 patch
Nick Coghlan wrote: Alex Martelli wrote: On Mar 12, 2006, at 11:16 AM, Ian Bicking wrote: ... memoize seems to fit into functools fairly well, though deprecated not so much. functools is similarly named to itertools, another module that is kind of vague in scope (though functools is much more vague). partial would make just as much sense in functools as in functional. Couldn't we merge functools and functional into just one (user- visible) module? The distinction between what goes into one vs the other is exceedingly subtle and poor users will be guessing as to what's where. If we need a mixed module with something in C and something in Python, we can do it the usual way, func.py wrapping _func.pyd (or .so or whatever)... I agree it makes sense to have decorator, memoize, deprecated and partial all being members of the same module, whether the name be functools or functional (although I have a slight preference for functools due to the parallel with itertools). +1 from me. I'll happily make the according changes if that reaches a consensus. On the question of whether or not deprecated fits in as a function tool, I know I'd tend to only use it on functions (to deprecate a class, I'd simply decorate the class's __init__ or __new__ method). I suppose it would be okay, since as a decorator it can only be applied to functions. In PEP 356, there is even a suggestion to add builtin @deprecated decorator?. Cheers, Georg ___ 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 patch
In PEP 356, there is even a suggestion to add builtin @deprecated decorator?. Restraint please. Go easy on the decorator additions. Raymond ___ 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 patch
On 3/12/06, Raymond Hettinger [EMAIL PROTECTED] wrote: [Nick Coghlan] I agree it makes sense to have decorator, memoize, deprecated and partial all being members of the same module, whether the name be functools or functional (although I have a slight preference for functools due to the parallel with itertools). I like functools for a different reason -- the name is sufficiently broad so that we don't have fret about whether a particular tool fits within the module's scope. In contrast, a name like functional suggests that some of these tools don't quite fit. FWIW, +1 here. Especially if we're only going to add two functions -- ``partial``, which is already accepted, and Georg's ``decorator`` -- it seems like overkill to introduce a module for each. I agree that functools is a better module name if both ``partial`` and ``decorator`` are going in there. STeVe -- Grammar am for people who can't think for myself. --- Bucky Katt, Get Fuzzy ___ 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 patch
Raymond Hettinger wrote: In PEP 356, there is even a suggestion to add builtin @deprecated decorator?. Restraint please. Well, that sentence wasn't meant in the sense of we should add it but in the sense of why shouldn't we put it in functools _if_ we add it, when it's even suggested as a builtin ;) Georg ___ 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
