[Python-Dev] Considering decorator syntax on an individual feature basis

[Josiah Carlson]

> The features in question, which should be decided individually rather than as a
> whole:

Sounds good.  I'll do something different here and remove your and my
opinions from this post, and stick to "facts", or at least statements
that can be reasonably derived from "facts..


> - decorator before/within/after def.

While I understand that Python is not a democracy, voting does allow us
to discover certain preferences within the community.

According to the informal poll linked from the Python decorators wiki,
that I posted about earlier, which seemed to have gotten no response,
Guido's before approach is in the minority according to the community;
"list within def" and "@ after def" favorites by a clear margin.

A. @classmethod def foo(): (107)   16%
C1. def foo() [classmethod]: (269) 39%
E1. def foo(): @classmethod (311)  45%

The fact that the two favored syntax families have been rejected by
Guido suggests that the community has strong opinions either against
@before, or in favor of [] within or @after.

Based on people's statements against the @ symbol in the @before syntax,
the voting suggests that location plays an important role, as @ before
has slightly more than 34% as many votes as @after (or 40% as many as
list within).

It seems that those who voted for C1 disagree with the formatting
argument presented against C1, and those who voted for E1 think that
within the block is the proper location for decorators.


> - special character/keyword/no new symbol.

All of which are options in all three before, within and after def
syntax families.  If a symbol is necessary for the location that is
chosen, perhaps an informal poll to choose the favorite within the
community is in order.


> - decorator on one/many line(s)
> - one symbol per decorator vs. one symbol for all decorators

Not really relevant.  If we allow:
    @decorator(arg1, arg2)

Then one/many lines and one/many symbols is a simple user-supplied
decorator away, regardless of the underlying syntax.


> - indent def/not indent def

Mostly J1 vs every other option.  Due to the lack of a reasonable number
of people posting with "indentation is the right way" on python-dev
during that flurry of hundreds of emails, I don't believe indenting the
def is remotely in the running.


> 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.

Agreed.


> I think the Python community has mostly settled on a "before def" approach, and

The informal poll numbers say otherwise.


 - Josiah