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
10  1423 
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
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(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.
"DH" <no@sp.am> wrote in message news:r4******** ************@co mcast.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 "progressin g" beyond that scope. http://mail.python.org/pipermail/pyt...ch/043566.html
(where Josiah Carlson tries to reign in the discussion)
Il Sun, 28 Mar 2004 11:59:03 -0500, Sean Ross ha scritto: # [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
# [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/
"Sean Ross" <sr***@connectm ail.carleton.ca > wrote in message
news:7v******** **********@news 20.bellglobal.c om... 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:"DO C:= HEAD BODY FOOT",
url="/cgi-bin/directory/directory"}
"doc string"
body
# [5B]
def f(self)::
"doc string"
publish_to_web( foo)
{spark_rule:"DO C:= HEAD BODY FOOT",
url="/cgi-bin/directory/directory"}
:
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
# [6B]
def foo(self)::
"doc string"
publish_to_web( foo)
spark_rule="DOC := HEAD BODY FOOT"
url="/cgi-bin/directory/directory"
:
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
#[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
"Sean Ross" <sr***@connectm ail.carleton.ca > wrote in message
news:7v******** **********@news 20.bellglobal.c om... 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 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
"Terry Reedy" <tj*****@udel.e du> wrote in message
news:ma******** *************** **************@ python.org...
"Sean Ross" <sr***@connectm ail.carleton.ca > wrote in message
news:7v******** **********@news 20.bellglobal.c om... 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:"DO C:= HEAD BODY FOOT",
url="/cgi-bin/directory/directory"}
"doc string"
body
# [5B]
def f(self)::
"doc string"
publish_to_web( foo)
{spark_rule:"DO C:= HEAD BODY FOOT",
url="/cgi-bin/directory/directory"}
:
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
# [6B]
def foo(self)::
"doc string"
publish_to_web( foo)
spark_rule="DOC := HEAD BODY FOOT"
url="/cgi-bin/directory/directory"
:
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
#[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
On Sun, 28 Mar 2004 11:59:03 -0500, Sean Ross <sr***@connectm ail.carleton.ca > wrote:
# [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)
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 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
"""
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) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: ajsiegel |
last post by:
Arthur wrote:
>> And either intuitively, or consciously, he is doing something that
>> offsets it from something truly intergrated into the core of the
>> language. By breakling all of his own rules.
>But it *isn't* part of the core language. I think that's the whole
>point. @decorator does something that no other statement in Python does,
>so why should it *look* like a normal statement? Or are you suggesting
>that a keyword should be...
|
by: Arien Malec |
last post by:
Apologies for feeding the fire, when we are rallying around a consensus,
but I've been concerned about the clash between syntax and semantics, and
I've finally reached a mini-epiphany:
The problem with PEP318 is that it is too powerful, and tries to do too
much. It is a sledgehammer for attacking three problems:
1) Metadata, a la Java and C#
2) class & static method defs
3) Arbitrary post-definitional transformations of functions.
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
| | |
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
