As I see it, any decorator that appears on lines previous to a function impairs code readability by making the function harder to find. When editing code with the standard 4-space tab, the function name is very conveniently lined up with the code below it, and in most code I've seen, there's a blank line above it, like this: def something(foo): do_something() def somethingelse(bar): do_something_else() Now say we were to add decorators to this. Then visually, to find the function, you'd be searching through a non-predetermined set of decorators first, as opposed to searching for a solid piece of whitespace then scrolling your eyes one line down, a fixed position from the left edge of the editor. The function name would be embedded in noise, making the code more confusing to edit. This particular issue can be remedied in two ways. First off, a list of decorators with brackets, as Phillip's solution makes possible, but with some limitation to prevent multiple lines of them (or at least a prescribed coding convention prohibiting it without true enforcement). It would still take away from readability a little bit, but not in such a bad way. The brackets actually set off the decorators nicely. Something like: [decorators] def func(args): pass The other solution I see is something like what Bill said which is: def func (args) as [decorators]: The idea of bracketing them as a list is, I think, a very good one, and it would of course still have to be determined whether decorators are functions, whether they should be called, etc. I kind of like the idea of them being functions that are called on the function, and if they need additional arguments, make them higher order functions such that the decorator list element is called with func as its argument. Just my 2c, Brian On Fri, 25 Jun 2004 16:18:38 -0400, Fred L. Drake, Jr. <fdrake@acm.org> wrote:
On Friday 25 June 2004 04:09 pm, Phillip J. Eby wrote:
* Whether to have a 'decorate' function at all, or whether it's better to just list specialized decorator objects/functions (I generally favor the latter, since 'decorate' is IMO a dead chicken that hasn't appeared in any widely-supported syntax proposals to date).
Ooohh... time for some fun! Some proposals have included "as". Since "as" isn't really a keyword, how about:
from decorate import decorate as as
as(classmethod) def myAlternateConstructor(...): # make something interesting: return 42
Too bad this is ugly for the simple attribute decorator:
as(spam="fidget") def foo(...): send_fred_more_spam_please()
-Fred
-- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
_______________________________________________ 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/zorander%40gmail.com
-- The years ahead pick up their dark bags. They move closer. There's a slight rise in the silence then nothing.