map vs. list-comprehension

George Sakkis gsakkis at rutgers.edu
Fri Jul 1 09:43:35 CEST 2005


"Terry Hancock" wrote:

> On Thursday 30 June 2005 09:49 am, Mike P. wrote:
>
> > IMHO I'm not particularly happy with the way Python is going language wise.
> > I mean, I don't think I'll ever use decorators, for example. Personally, in
> > terms of language features and capabilities I think the language is fine.
> > Not much (if anything needs to be added).
>
> This though, I mostly agree with. I'm not sure if I'll ever find use for decorators,
> but the "@" signs bother me, I must admit. I liked the fact that there was a
> way to do this without fiddling with the language syntax.

What way ? The foo=decorator(foo) workaround after the function's body
? That's hardly acceptable for common decorators such as staticmethod,
classmethod and other suggested ones (synchronized, cached, traced,
etc.). I don't mind the @ so much - I don't like it particularly either
- and I don't compare it to the alternative rejected decorator syntax
forms, but it's certainly an improvement over the pre-2.4 explicit
assignment *after* the function.

Properties are in the same boat with decorators. Although they are
great semantically, the current syntax is less than optimal.
Interestingly, Pyrex does much better in the readability department
since 0.9
(http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/version/Doc/extension_types.html#Properties).
The Property decorator recipe
(http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/410698) comes
pretty close to it, but I wouldn't mind a small addition to the
language syntax for something so useful as properties.

Keeping the language small is a worthwhile goal, but it should be
traded off with conciseness and readability; otherwise we could well be
content with s-expressions.

Just my $0.02,

George




More information about the Python-list mailing list