Using 'apply' as a decorator, to define constants
Jonathan Fine
jfine at pytex.org
Fri Aug 21 15:23:51 EDT 2009
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
More information about the Python-list
mailing list