Guido van Rossum wrote:
> ...while far from perfect, in
> terms of readability setting function attributes in a decorator is so
> much better than setting them after the function has been defined,
> that I believe we have no choice but to provide it.
The more I read statements like this, the more I think of replacing:
def foo(arg1, arg2):
pass
foo = classmethod(foo)
foo.attrA = 3
...with code like:
foo = classmethod()
foo.attrA = 3
def foo(arg1, arg2):
pass
...the meaning of "def" changes from "make a function" to "bind this
suite to foo". OBVIOUSLY, this would be a huge change as I've written
it. But perhaps, having seen this ideal, a middle ground might become
more visible.
> I also note that accepting decorator-before-colon now would make it
> harder to come up with a decent syntax for declaring the return type,
> which I still want to do in some future version of Python with
> optional (!) static typing. But not impossible -- there's enough
> punctuation available besides '[' and ':'.
Why would such additional features not be standard attributes of
function objects?
foo = function()
foo.returns(int)
def foo(arg1):
return int(arg1)
All in all, I'd prefer that function decorators and attributes use
simple, known techniques like assignment and callables (as shown above),
than become monolithic, crystallized all-in-one statements like:
def foo(arg1 as str, arg2 as int) returns str [classmethod] {attrA: 3}:
I understand the desire to keep all those bits near each other on the
page, but stronger is my desire to make them independent statements. If
we could bind a "blank" function object and supply its actual codeblock
in a later statement, the rest falls magically into place, IMO.
Just some thoughts.
Robert Brewer
MIS
Amor Ministries
fumanchu at amor.org
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