> From: Guido van Rossum
>
> OTOH, for long argument lists, the "preferred" form has the reverse
> problem: the decorators are separated from the function name by the
> long argument list.
>
> The question then becomes, what is more likely: long argument lists or
> long lists of decorators? I *know* that (at least in certain code
> bases :) long argument lists are common. Will long lists of
> decorators ever become popular? I think we'll have to look for
> languages that already have decorators (especially C#) for what the
> future might give. I'll be talking to folks at PyCon about this.
I've come back to this, because I've finally solidified one reason why I think the form:
def func (args) [decorators]:
is my preference. I've seen this expressed obliquely by other people, but not explicitly, so I want to add it as an explicit argument now.
The first part of the definition:
def func (args)
is *required* for every function definition. However, the [decorators] part is *optional*. I think this distinction is very important - we can guarantee that if we use the format:
def func (args) [decorators]:
then every function signature looks the same - name; arguments; optional decorators. OTOH, if we go with:
def func [decorators] (args):
then function signatures look different in different places.
A side issue is that due to the conventions used in command lines and the python documentation, the first form actually *reads* like "def name arguments optional decorators" - c.f. range([start,] stop[, step]) - which may or may not be a good thing. Would it contribute to people thinking the [] weren't part of the decorator list, but merely a documentation thing?
Tim Delaney
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4