[Python-Dev] Re: def fn (args) [dec,dec]:
Edward K. Ream
edreamleo at charter.net
Fri Aug 6 17:08:04 CEST 2004
[quote]
Problems with this form:
- it hides crucial information (e.g. that it is a static method)
after the signature, where it is easily missed
- it's easy to miss the transition between a long argument list and a
long decorator list
- it's cumbersome to cut and paste a decorator list for reuse, because
it starts and ends in the middle of a line
Given that the whole point of adding decorator syntax is to move the
decorator from the end ("foo = staticmethod(foo)" after a 100-line
body) to the front, where it is more in-your-face, it should IMO be
moved all the way to the front.
[end quote]
Ah Jeeze :-) Are you really, truly saying that you want to introduce @ to
help people format their declarations? This just seems like complete
nonsense to me.
How about:
class C(object):
def longMethodNameForEffect(
longArgumentOne=None,
longArgumentTwo=42)\
[
staticmethod,
funcattrs(grammar="'@' dotted_name [ '(' [arglist] ')' ]",
status="experimental", author="BDFL")
]:
SNIP
or even:
class C(object):
def longMethodNameForEffect(
longArgumentOne=None,
longArgumentTwo=42)\
\
# ***** DECORATION *****
[
staticmethod,
funcattrs(grammar="'@' dotted_name [ '(' [arglist] ')' ]",
status="experimental", author="BDFL")
]:
SNIP
Isn't "a total jumble of stuff ending with a smiley." a complete red
herring? Look, there is a lot of information that has to be presented,
whatever the means. How is _any_ syntax going to simplify:
funcattrs(grammar="'@' dotted_name [ '(' [arglist] ')' ]",
status="experimental", author="BDFL")
??
And are you seriously saying that problems cutting and pasting should drive
this discussion?
real-python-programmers-don't-need-help-formatting-ly yours,
Edward
P.S. In Leo one would render this:
class C(object):
def longMethodNameForEffect(
longArgumentOne=None,
longArgumentTwo=42) [
<< decoration for longMethodNameForEffect >>
]:
SNIP
but I suppose that's not relevant :-) BTW, << decoration for
longMethodNameForEffect >> would be syntax colored in red by default (with
blue << and >>) so it would stand out.
EKR
--------------------------------------------------------------------
Edward K. Ream email: edreamleo at charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
More information about the Python-Dev
mailing list