[Python-Dev] Considering decorator syntax on an individual feature basis (original) (raw)
Martin Zarate mzarate at uoguelph.ca
Thu Aug 19 18:13:11 CEST 2004
- Previous message: [Python-Dev] SF Priorities, 2.4 release
- Next message: [Python-Dev] Considering decorator syntax on an individual feature basis
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Issues with decorator syntax.
I think we can all agree that the decorator argument is now wholly a matter of aesthetic taste, with the brief exception of namespace-based stuff that got argued when I suggested to use a block instead.
The problem is that we keep jumping from the beginning of the argument to the end - we keep saying "what syntax do we want" rather than "which syntactic features do we want".
The features in question, which should be decided individually rather than as a whole:
decorator before/within/after def. Guido is obviously a fan of the "before" approach, and I agree. The "after" to me is just ugly, and the "within" (on the same line, I mean) is impractical for some of the lengthier uses people describe for decorators, although I think that it is the most "pythonic" in general appearance.
special character/keyword/no new symbol. Guido prefers the @ character (I dislike it - it looks meaningless, and it breaks existing tools - I find it unpythonic). The "no new symbol" approach (such as the "list before def", or decorator-after-def-before-name) is often difficult to parse and, while elegant looking, can make it visually difficult to distinguish the decorators (and hard to grep). As such, I prefer the new keyword statement approach - it is more verbose, but I like it.
decorator on one/many line(s) The approach described by the paired-block syntax, and the @ syntax both assume that users want to include only one decorator per line. Personally, I am inclined to follow something like the new import statment wherein the user can have a comma-delimited list of decorators and can span the list across lines if they so choose.
one symbol per decorator vs. one symbol for all decorators The @ approach has one symbol for each decorator. The block approach has one symbol that encompasses all decorators. If a single symbol is used, then one must consider whether that symbol occurs on the same line as the decorators or not. If not, then the symbol must be brief to avoid letting its repetition be clumsy. Personally, I prefer a single use of the symbol, but its really personal taste.
indent def/not indent def If the decorator is before the def, this must be considered. Indenting the def is very Pythonic, as it shows the heirarchial relationship visually... but it also seems an unnecessary indendation in this case, as there is no other case where an indentation occurs for the benefit of a single statement.
I think if each of these issues could be resolved and agreed to individually, then a consensis would be far more apparent as to the ideal solution, or at least some of the myriad solutions could be filtered out.
I think the Python community has mostly settled on a "before def" approach, and I think that most agree that the @ character is very ugly, but some are coming around (mostly out of exhaustion though, it sounds). So if we can agree on the latter considerations. Personally, my favourite would be a single-line but continuable statement (like the "import" statement) which causes the assignment that occurs on the following line be wrapped by its mentioned objects. Use a nice keyword like deco or remake (or even just "be"). Possibly indent the def one level to show the relationship of the import statement and to allow for def assignments to look good when used with the statement.
The fact is that there is no Pythonic precedence here - we're talking about a statement that holds one other statement and has N parameters. Whenever Python has had to break into new ground with statements, its been a bit of a mess (take lambda for example).
Oh, and in defense of "be" as a statement - how's this?
be staticmethod, returning(int), taking(int, bool, bool) def foo: pass
or
be ( staticmethod, synchronised): foo = lambda: none
but that's just my tastes. Oh well, I'm violating my own rule, jumping ahead with a full syntax when we can't even find consensus on the parts of it.
- Previous message: [Python-Dev] SF Priorities, 2.4 release
- Next message: [Python-Dev] Considering decorator syntax on an individual feature basis
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]