Michael wrote:
> I don't object to a syntax for function attributes... in fact, I've seen no
> specific proposal to object to. But I find your point above HIGHLY
> unconvincing:
I agree that
def sqr(x):
return x*x
sqr.inline = true
is about the same length as
def sqr [inline=true](x):
return x*x
But when this function is 60 lines long rather than 2 lines long, the
association is broken. This is my major objection, not the number
of characters I write, but rather the number of lines I must scan.
People wouldn't be as likely to use doc strings if the syntax was:
def function(x):
code
code code code
function.__doc__ = "this is my doc string"
> Notice that this is the approach that Guido used for classmethod and
> its ilk, and we're still working out what the right "special syntax"
I use the classmethod call because its the only (good) way to do
the task, but I have the same objection. When I write
class Foo:
def method(self, ...):
...
method = classmethod(method)
Upon reading, I don't find out the "true meaning" of the method until I
happen upon the classmethod call.
Even in C++ with its bogus syntax, I can identify a class method at the
point of definition
class Foo {
static void method(...);
...
}
so, it would be nice if there was a way to densely associate the
information at the point of function definition just as the doc
string is densely associated with the function definition.
class Foo:
def method [classmethod=true](self, ...):
"doc string"
def get_x [property="x"](self):
return self.__x
--
Patrick Miller | (925) 423-0309 | http://www.llnl.gov/CASC/people/pmiller
The more original a discovery, the more obvious it seems afterward.
-- Arthur Koestler
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