Breakdown of approaches to PEP318

[Sean Ross]

Here's a breakdown of most of the syntax discussed re: PEP318 using an
example from python-dev. There are probably several more (I've added [10]).
The example applies both function decoration and annotation.


# [1] .. [3], competing ways to say the same thing

# [1]
def foo(self) [attrs(spark_rul e="DOC := HEAD BODY FOOT",
url="/cgi-bin/directory/directory"),
publish_to_web]:
"doc string"
body

# [2]
def foo[attrs(spark_rul e="DOC := HEAD BODY FOOT",
url="/cgi-bin/directory/directory"),
publish_to_web](self):
"doc string"
body

# [3]
def [attrs(spark_rul e="DOC := HEAD BODY FOOT",
url="/cgi-bin/directory/directory"),
publish_to_web] foo(self):
"doc string"
body


# [4] now once with 'as' - sub in your 'favourite': "using", "with", ...
def foo(self) as attrs(spark_rul e="DOC := HEAD BODY FOOT", \
url="/cgi-bin/directory/directory"), \
publish_to_web:
"doc string"
body


# [5] function attribute dictionary
def foo(self)[publish_to_web]:
{spark_rule:"DO C:= HEAD BODY FOOT",
url="/cgi-bin/directory/directory"}
"doc string"
body


# [6] @function_attri bute = ...
def foo(self)[publish_to_web]:
@spark_rule="DO C:= HEAD BODY FOOT"
@url="/cgi-bin/directory/directory"
"doc string"
body


# [7] :function_attri bute:...
def foo(self)[publish_to_web]:
:spark_rule:"DO C:= HEAD BODY FOOT"
:url:"/cgi-bin/directory/directory"
"doc string"
body



# [8] special purpose blocks - several variations proposed
with this:
spark_rule = "DOC:= HEAD BODY FOOT"
url = "/cgi-bin/directory/directory"
using:
publish_to_web
def foo(self):
"doc string"
body


# [9] some form of doc string abuse - one syntax option ...
def foo(self):
"""doc string
@:
foo.spark_rule= "DOC:=HEAD BODY FOOT",
foo.url="/cgi-bin/directory/directory")
foo = publish_to_web( foo)
"""
body





# [10] metaclass approach - only works inside classes
decorate("foo", publish_to_web,
spark_rule="DOC :=HEAD BODY FOOT",
url="/cgi-bin/directory/directory")

def foo(self):
"doc string"
body



# [11] current method
def foo(self):
"doc string"
very
long
body
....
foo.spark_rule = "DOC:=HEAD BODY FOOT",
foo.url="/cgi-bin/directory/directory")
foo = publish_to_web( foo)





Personally, I find all of this very off-putting. I find none of these
proposals clean, clear, and/or readable, except perhaps [11] (which started
the whole mess in the first place). I tend to agree with the following,
somewhat out of context, remark:


"""
If only we could learn from others' mistakes:

Finally, in designing Self, we have learned one lesson by making mistakes:
examples can persuade the designer to include additional features which
later turn out to produce incomprehensibl e behavior in unforeseen
circumstances. This might be called the language designer's trap.
Minimalism, simplicity and consistency are better guides. They benefit every
programmer, not just the ones who need advanced features. We suspect that
many of today's object-oriented languages could profit by dropping features.

Programming as an Experience: The Inspiration for Self
"""
Isaac Gouy, http://lambda.weblogs. com/discuss/msgReader$11653

[Sean Ross]

Re: Breakdown of approaches to PEP318

One more:

# [12] based on

http://mail.python.org/pipermail/python-dev/2004-March/043613.html

[publish_to_web]
def foo(self):
{spark_rule:"DO C:= HEAD BODY FOOT",
url="/cgi-bin/directory/directory"}
"doc string"
body

[Sean Ross]

Re: Breakdown of approaches to PEP318

That last one had an error, here it is again:

[publish_to_web]
def foo(self):
{spark_rule:"DO C:= HEAD BODY FOOT",
url:"/cgi-bin/directory/directory" }
"doc string"
body

[DH]

Re: Breakdown of approaches to PEP318

Sean Ross wrote:
[color=blue]
> Here's a breakdown of most of the syntax discussed re: PEP318 using an
> example from python-dev. There are probably several more (I've added [10]).
> The example applies both function decoration and annotation.[/color]

These are all ugly and unreadable. If you had to do this I'd go with #9
docstrings, but use javadoc (only the @ parts).

Actually it looks like epydoc already does this:

http://epydoc.sourceforge.net/

See their example:

http://epydoc.sourceforge.net/epytextintro.html

and list of all @tags:

http://epydoc.sourceforge.net/fields.html

An example with function decorators too:

def addObserver(sel f, obs) [synchronized, classmethod]:
"""
Add an observer to be notified when something changes.

@author: John Smith
@deprecated: The reason why this is deprecated.
@param obs: The observer, a class with a "notify" method or
else a function or callable.
"""

Note though this all really is beyond the initial scope of PEP 318.

[Sean Ross]

Re: Breakdown of approaches to PEP318

"DH" <no@sp.am> wrote in message news:r4idnebU2M fTkvrdRVn-uA@comcast.com. ..
[snip][color=blue]
> These are all ugly and unreadable.[/color]

I agree.

[color=blue]
> Note though this all really is beyond the initial scope of PEP 318.[/color]

Yep. The discussion is "progressin g" beyond that scope.

http://mail.python.org/pipermail/python-dev/2004-March/043566.html

(where Josiah Carlson tries to reign in the discussion)

[Valentino Volonghi aka Dialtone]

Re: Breakdown of approaches to PEP318

Il Sun, 28 Mar 2004 11:59:03 -0500, Sean Ross ha scritto:
[color=blue]
> # [7] :function_attri bute:...
> def foo(self)[publish_to_web]:
> :spark_rule:"DO C:= HEAD BODY FOOT"
> :url:"/cgi-bin/directory/directory"
> "doc string"
> body[/color]
[color=blue]
> # [11] current method
> def foo(self):
> "doc string"
> very
> long
> body
> ....
> foo.spark_rule = "DOC:=HEAD BODY FOOT",
> foo.url="/cgi-bin/directory/directory") foo = publish_to_web( foo)[/color]
[color=blue]
> Personally, I find all of this very off-putting. I find none of these
> proposals clean, clear, and/or readable, except perhaps [11] (which
> started the whole mess in the first place). I tend to agree with the
> following, somewhat out of context, remark:[/color]

Just look at those 2 above... They are almost the same, really clear.

My vote goes to number 7.

+1 for 7

--
Valentino Volonghi aka Dialtone
Linux User #310274, Gentoo Proud User
X Python Newsreader developer

http://sourceforge.net/projects/xpn/

[Terry Reedy]

Re: Breakdown of approaches to PEP318


"Sean Ross" <sross@connectm ail.carleton.ca > wrote in message
news:7vD9c.318$ 1A6.114130@news 20.bellglobal.c om...[color=blue]
> Here's a breakdown of most of the syntax discussed re: PEP318 using an
> example from python-dev. There are probably several more (I've added[/color]
[10]).[color=blue]
> The example applies both function decoration and annotation.[/color]

Let me add two more based on a proposal I just posted to PyDev.
[color=blue]
> # [5] function attribute dictionary
> def foo(self)[publish_to_web]:
> {spark_rule:"DO C:= HEAD BODY FOOT",
> url="/cgi-bin/directory/directory"}
> "doc string"
> body[/color]


# [5B]
def f(self)::
"doc string"
publish_to_web( foo)
{spark_rule:"DO C:= HEAD BODY FOOT",
url="/cgi-bin/directory/directory"}
:
body
[color=blue]
> # [6] @function_attri bute = ...
> def foo(self)[publish_to_web]:
> @spark_rule="DO C:= HEAD BODY FOOT"
> @url="/cgi-bin/directory/directory"
> "doc string"
> body[/color]

# [6B]
def foo(self)::
"doc string"
publish_to_web( foo)
spark_rule="DOC := HEAD BODY FOOT"
url="/cgi-bin/directory/directory"
:
body
[color=blue]
> # [7] :function_attri bute:...
> def foo(self)[publish_to_web]:
> :spark_rule:"DO C:= HEAD BODY FOOT"
> :url:"/cgi-bin/directory/directory"
> "doc string"
> body[/color]

#[7B] identical to [6B]

The essential idea is that definition-time code should be strictly
separated from run-time code with ':'. If so, no new syntax is *necessary*
(though some can be considered). Assignments in the def-block would be
interpreted much like in class bodies (which are also executed at def
time).

Terry J. Reedy

[John Roth]

Re: Breakdown of approaches to PEP318


"Sean Ross" <sross@connectm ail.carleton.ca > wrote in message
news:7vD9c.318$ 1A6.114130@news 20.bellglobal.c om...[color=blue]
> Here's a breakdown of most of the syntax discussed re: PEP318 using an
> example from python-dev. There are probably several more (I've added[/color]
[10]).[color=blue]
> The example applies both function decoration and annotation.
>
>
>
> Personally, I find all of this very off-putting. I find none of these
> proposals clean, clear, and/or readable, except perhaps [11] (which[/color]
started[color=blue]
> the whole mess in the first place). I tend to agree with the following,
> somewhat out of context, remark:[/color]

What makes them unreadable is the attempt to put parameters
into the decorators. This shoves the entire enterprise out over
a number of lines. The mixture of all upper case with the rest
of the syntax lends touch of impenetrability to them.

As far as I can tell, Python has hit an architectural limit on
the design of the function/code block. Some things are simply not
extendable without making compromises, and I think that the design
of the 'def' statement, combined with the indentation rules, is one
of them.

John Roth

[color=blue]
>
>
> """
> If only we could learn from others' mistakes:
>
> Finally, in designing Self, we have learned one lesson by making mistakes:
> examples can persuade the designer to include additional features which
> later turn out to produce incomprehensibl e behavior in unforeseen
> circumstances. This might be called the language designer's trap.
> Minimalism, simplicity and consistency are better guides. They benefit[/color]
every[color=blue]
> programmer, not just the ones who need advanced features. We suspect that
> many of today's object-oriented languages could profit by dropping[/color]
features.[color=blue]
>
> Programming as an Experience: The Inspiration for Self
> """
> Isaac Gouy, http://lambda.weblogs. com/discuss/msgReader$11653
>
>[/color]

[John Roth]

Re: Breakdown of approaches to PEP318


"Terry Reedy" <tjreedy@udel.e du> wrote in message
news:mailman.17 .1080508539.201 20.python-list@python.org ...[color=blue]
>
> "Sean Ross" <sross@connectm ail.carleton.ca > wrote in message
> news:7vD9c.318$ 1A6.114130@news 20.bellglobal.c om...[color=green]
> > Here's a breakdown of most of the syntax discussed re: PEP318 using an
> > example from python-dev. There are probably several more (I've added[/color]
> [10]).[color=green]
> > The example applies both function decoration and annotation.[/color]
>
> Let me add two more based on a proposal I just posted to PyDev.
>[color=green]
> > # [5] function attribute dictionary
> > def foo(self)[publish_to_web]:
> > {spark_rule:"DO C:= HEAD BODY FOOT",
> > url="/cgi-bin/directory/directory"}
> > "doc string"
> > body[/color]
>
>
> # [5B]
> def f(self)::
> "doc string"
> publish_to_web( foo)
> {spark_rule:"DO C:= HEAD BODY FOOT",
> url="/cgi-bin/directory/directory"}
> :
> body
>[color=green]
> > # [6] @function_attri bute = ...
> > def foo(self)[publish_to_web]:
> > @spark_rule="DO C:= HEAD BODY FOOT"
> > @url="/cgi-bin/directory/directory"
> > "doc string"
> > body[/color]
>
> # [6B]
> def foo(self)::
> "doc string"
> publish_to_web( foo)
> spark_rule="DOC := HEAD BODY FOOT"
> url="/cgi-bin/directory/directory"
> :
> body
>[color=green]
> > # [7] :function_attri bute:...
> > def foo(self)[publish_to_web]:
> > :spark_rule:"DO C:= HEAD BODY FOOT"
> > :url:"/cgi-bin/directory/directory"
> > "doc string"
> > body[/color]
>
> #[7B] identical to [6B]
>
> The essential idea is that definition-time code should be strictly
> separated from run-time code with ':'. If so, no new syntax is[/color]
*necessary*[color=blue]
> (though some can be considered). Assignments in the def-block would be
> interpreted much like in class bodies (which are also executed at def
> time).[/color]

Now, that's an interesting thought that I didn't get out of the discussion.

John Roth[color=blue]
>
> Terry J. Reedy
>
>
>
>
>[/color]

[phil hunt]

Re: Breakdown of approaches to PEP318

On Sun, 28 Mar 2004 11:59:03 -0500, Sean Ross <sross@connectm ail.carleton.ca > wrote:[color=blue]
>
># [11] current method
>def foo(self):
> "doc string"
> very
> long
> body
> ....
>foo.spark_ru le = "DOC:=HEAD BODY FOOT",
>foo.url="/cgi-bin/directory/directory")
>foo = publish_to_web( foo)[/color]

How about:


def foo(self):
this_method. spark_rule = "DOC:=HEAD BODY FOOT"
this_method.url ="/cgi-bin/directory/directory"
this_method = publish_to_web( this_method)
" doc string "
very
long
body

[color=blue]
>Personally, I find all of this very off-putting. I find none of these
>proposals clean, clear, and/or readable, except perhaps [11] (which started
>the whole mess in the first place).[/color]

I tend to agree with your sentiments.
[color=blue]
>I tend to agree with the following,
>somewhat out of context, remark:
>
>"""
>If only we could learn from others' mistakes:
>
>Finally, in designing Self, we have learned one lesson by making mistakes:
>examples can persuade the designer to include additional features which
>later turn out to produce incomprehensibl e behavior in unforeseen
>circumstance s. This might be called the language designer's trap.
>Minimalism, simplicity and consistency are better guides. They benefit every
>programmer, not just the ones who need advanced features. We suspect that
>many of today's object-oriented languages could profit by dropping features.
>
>Programming as an Experience: The Inspiration for Self
>"""[/color]

Indeed.

--
"It's easier to find people online who openly support the KKK than
people who openly support the RIAA" -- comment on Wikipedia
(Email: zen19725 at zen dot co dot uk)

[Josiah Carlson]

Re: Breakdown of approaches to PEP318

> def foo(self):[color=blue]
> this_method. spark_rule = "DOC:=HEAD BODY FOOT"
> this_method.url ="/cgi-bin/directory/directory"
> this_method = publish_to_web( this_method)
> " doc string "
> very
> long
> body[/color]

God no.

- Josiah