Purely emotional perspective

Heiko Wundram heikowu at ceosg.de
Mon Aug 9 14:41:06 EDT 2004


Am Montag, 9. August 2004 20:07 schrieb Peter Hansen:
> Heiko Wundram wrote:
> > The docstring of a function actually is only meta-data (in my taste), and
> > thus should remain inside the function definition.
>
> This argument makes no sense to me.  Why should any meta-data be inside
> the function body?  There should probably be one place where all
> meta-data is defined, and it should be used consistently for everything,
> docstrings included.  (The pie-syntaxians are heading that way, it
> seems.)

Basically, what I was trying to say:

decorators aren't necessarily meta-data. decorators may return a new function 
object which does something different than the actual function in question. 
Thus, you could divide decorators into two categories:

1) mutating decorators, which change the function object to be a new function 
(and thus introduce new functionality),

2) "decorating" decorators, which add information to the presented function 
object.

Docstrings are a decorator which falls into category 2, the example I gave 
falls into category 1. What my argument basically was:

Decorators which fall into category 2 may safely be hidden from the 
programmer, as they only give "meta-information" on the function in question, 
and don't change it's behavior, whereas decorators which fall into category 1 
may not be hidden from the programmer, as they change the functions behavior, 
and are thus important for understanding the function in question when 
reading the code.

Now, what I'd like to see (hypothetically) is to have decorators which mutate 
the function before the actual function, because they are "equivalent" to 
defining a function, whereas decorators which do "decorating" inside the 
function body (like the doc-string), because they are equivalent to setting 
an attribute on the function.

Now, certainly, making a distinction between the two is inappropriate, as it 
would only complicate code, but "hiding" mutating decorators inside the 
function body is also not the right way to go, so for me, it's clear that 
decorators should always be outside the function body.

But, I hold no grudge against keeping the doc-string inside the actual 
function (because this actually is meta-data, it has no influence on running 
the function), so the following is out of the question for me:

@doc("my doc-string")
def f():
	<blah>

> To tell the truth, I think I prefer the current approach, where the
> function is clearly, explicitly decorated *after* it has been defined,
> and no new syntax is required.

True, I use this approach a lot. But decorating a function with a clear sign 
before the actual method (@<somedecorator>) only makes the code more readable 
for me. As I've stated elsewhere, I've ported some code of mine to use 
decorators for 2.4, and I've really felt that the code became quite a bit 
more readable just by having this little bit of syntactic sugar.

> Python is clearly on a huge evolutionary surge and conservative views
> on the matter are definitely not winning out right now.

And that's fine. :-) Conservatism never did anybody any good. ;-)

Anyway, hope that clears up my position...

Heiko.



More information about the Python-list mailing list