By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,537 Members | 1,743 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,537 IT Pros & Developers. It's quick & easy.

Breakdown of approaches to PEP318

P: n/a
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_rule="DOC := HEAD BODY FOOT",
url="/cgi-bin/directory/directory"),
publish_to_web]:
"doc string"
body

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

# [3]
def [attrs(spark_rule="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_rule="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:"DOC:= HEAD BODY FOOT",
url="/cgi-bin/directory/directory"}
"doc string"
body
# [6] @function_attribute = ...
def foo(self)[publish_to_web]:
@spark_rule="DOC:= HEAD BODY FOOT"
@url="/cgi-bin/directory/directory"
"doc string"
body
# [7] :function_attribute:...
def foo(self)[publish_to_web]:
:spark_rule:"DOC:= 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 incomprehensible 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
Jul 18 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
One more:

# [12] based on
http://mail.python.org/pipermail/pyt...ch/043613.html
[publish_to_web]
def foo(self):
{spark_rule:"DOC:= HEAD BODY FOOT",
url="/cgi-bin/directory/directory"}
"doc string"
body
Jul 18 '05 #2

P: n/a
That last one had an error, here it is again:

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


Jul 18 '05 #3

P: n/a
DH
Sean Ross wrote:
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.


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(self, 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.
Jul 18 '05 #4

P: n/a
"DH" <no@sp.am> wrote in message news:r4********************@comcast.com...
[snip]
These are all ugly and unreadable.
I agree.

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


Yep. The discussion is "progressing" beyond that scope.

http://mail.python.org/pipermail/pyt...ch/043566.html
(where Josiah Carlson tries to reign in the discussion)
Jul 18 '05 #5

P: n/a
Il Sun, 28 Mar 2004 11:59:03 -0500, Sean Ross ha scritto:
# [7] :function_attribute:...
def foo(self)[publish_to_web]:
:spark_rule:"DOC:= HEAD BODY FOOT"
:url:"/cgi-bin/directory/directory"
"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:


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/

Jul 18 '05 #6

P: n/a

"Sean Ross" <sr***@connectmail.carleton.ca> wrote in message
news:7v******************@news20.bellglobal.com...
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.
Let me add two more based on a proposal I just posted to PyDev.
# [5] function attribute dictionary
def foo(self)[publish_to_web]:
{spark_rule:"DOC:= HEAD BODY FOOT",
url="/cgi-bin/directory/directory"}
"doc string"
body

# [5B]
def f(self)::
"doc string"
publish_to_web(foo)
{spark_rule:"DOC:= HEAD BODY FOOT",
url="/cgi-bin/directory/directory"}
:
body
# [6] @function_attribute = ...
def foo(self)[publish_to_web]:
@spark_rule="DOC:= HEAD BODY FOOT"
@url="/cgi-bin/directory/directory"
"doc string"
body
# [6B]
def foo(self)::
"doc string"
publish_to_web(foo)
spark_rule="DOC:= HEAD BODY FOOT"
url="/cgi-bin/directory/directory"
:
body
# [7] :function_attribute:...
def foo(self)[publish_to_web]:
:spark_rule:"DOC:= HEAD BODY FOOT"
:url:"/cgi-bin/directory/directory"
"doc string"
body


#[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

Jul 18 '05 #7

P: n/a

"Sean Ross" <sr***@connectmail.carleton.ca> wrote in message
news:7v******************@news20.bellglobal.com...
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.

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:
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



"""
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 incomprehensible 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

Jul 18 '05 #8

P: n/a

"Terry Reedy" <tj*****@udel.edu> wrote in message
news:ma*************************************@pytho n.org...

"Sean Ross" <sr***@connectmail.carleton.ca> wrote in message
news:7v******************@news20.bellglobal.com...
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.


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

# [5B]
def f(self)::
"doc string"
publish_to_web(foo)
{spark_rule:"DOC:= HEAD BODY FOOT",
url="/cgi-bin/directory/directory"}
:
body
# [6] @function_attribute = ...
def foo(self)[publish_to_web]:
@spark_rule="DOC:= HEAD BODY FOOT"
@url="/cgi-bin/directory/directory"
"doc string"
body


# [6B]
def foo(self)::
"doc string"
publish_to_web(foo)
spark_rule="DOC:= HEAD BODY FOOT"
url="/cgi-bin/directory/directory"
:
body
# [7] :function_attribute:...
def foo(self)[publish_to_web]:
:spark_rule:"DOC:= HEAD BODY FOOT"
:url:"/cgi-bin/directory/directory"
"doc string"
body


#[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).
Now, that's an interesting thought that I didn't get out of the discussion.

John Roth
Terry J. Reedy


Jul 18 '05 #9

P: n/a
On Sun, 28 Mar 2004 11:59:03 -0500, Sean Ross <sr***@connectmail.carleton.ca> wrote:

# [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)
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

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 your sentiments.
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 incomprehensible 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
"""


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)
Jul 18 '05 #10

P: n/a
> 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


God no.

- Josiah
Jul 18 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.