[Python-Dev] (Specific syntax of) PEP 318 - function/method/class decoration (original) (raw)
Phillip J. Eby pje at telecommunity.com
Mon Mar 8 13:48:09 EST 2004
- Previous message: [Python-Dev] (Specific syntax of) PEP 318 - function/method/class decoration
- Next message: [Python-Dev] PEP 318 needs a rewrite
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
At 01:21 PM 3/8/04 -0500, Jewett, Jim J wrote:
Bob Ippolito:
> I would like to focus this thread to, specifically, if this syntax > should become part of Python. def name(args)[somethingelse]: -1. With more explicit and extensible syntax, I would be +1, but with this syntax, I'm -1. Why are you so insistent on the bare syntax? The only arguments I have seen are: (1) We already have it. The author himself said that the patch isn't final, and he can change the syntax. Even some semantic changes (testlist vs exprlist) may be OK. (2) It is shorter to type. Adding "as" or "mods" is fairly small compared to the names of the wrappers themselves, even in your examples. (3) New keywords are bad. Not as bad as overloading an old one with a new meaning.
(4) C# uses the [] to designate "attributes" of functions, classes, and parameters.
The positioning is different, though. C# puts the bracketed list of "attributes" at the beginning of the declarations, so if we were really following C#'s lead, the syntax would actually be:
class [interface] Foo:
def [classmethod] foo(cls):
...
or, even closer to C#:
[interface] class Foo:
[classmethod] def foo(cls):
...
but that's really ugly.
Anyway, I seem to recall that the bracketed syntax was originally inspired by C#'s attribute mechanism, but you'd have to ask the original author to be sure.
- Previous message: [Python-Dev] (Specific syntax of) PEP 318 - function/method/class decoration
- Next message: [Python-Dev] PEP 318 needs a rewrite
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]