alex23 wrote:
Unfortunately, apply() has been removed as a built-in in 3.x. I'm not
sure if it has been relocated to a module somewhere, there's no
mention of such in the docs.
The old use of apply()
You can save yourself the tidy up by using the same name for the
function & the label:
def tags():
value = []
# ...
return value
tags = tags()
I don't like that because there's no hint at
def tags():
that this is /not/ the value of tags.
Like all uses of decorators, it is simply syntactic sugar. It allows
you to see, up front, what is going to happen. I think, once I get used
to it, I'll get to like it.
The question is, is it really that useful, or is it just a slight
aesthetic variation? Given that apply(f, args, kwargs) is identical to
f(*args, **kwargs), it's understandable that's apply() isn't seen as
worth keeping in the language.
Yes, I agree with that, completely.
Why I've personally stopped using it: I've always had the impression
that decorators were intended to provide a convenient and obvious way
of augmenting functions.
Yes, that was the intended use case.
Having one that automatically executes the
function at definition just runs counter to the behaviour I expect
from a decorator.
I'd expect the name of the decorator to explain what is going on. If
apply() were a well known part of the language, that would be fine.
Especially when direct assignment... foo = foo
() ...is a far more direct and clear way of expressing exactly what is
happening.
Actually, I think the decorator approach is clearer. But that's just my
opinion, and not with the benefit of a lot of experience.
But that's all IMO, if you feel it makes your code cleaner and don't
plan on moving to 3.x any time soon (come on in! the water's great!),
go for it :)
Thank you for your comments, Alex. And particularly for telling me that
apply() is no longer a builtin for Python 3.
--
Jonathan
--
http://mail.python.org/mailman/listinfo/python-list
