Decorator keyword options

[Paul McGuire]

Thanks to everyone who has voted so far - please keep them coming! Lurkers,
this means you!

In the interests of saving time, I propose that an additional thread start
soon, to determine choices for a decorator keyword, in the event that our
selected syntax requires one. Please visit the PythonDecorators Wiki page,
and navigate to section 6.1 Indicators (or follow this link
http://www.python.org/moin/PythonDec...8529997f56fc9e )
(not sure how reliable this is?) I have started numbering the options in
preparation for another voting thread, if you have other proposals, please
include them on this Wiki page, along with your +/0/- commentary.

-- Paul

[David Fraser]

Paul McGuire wrote:

Thanks to everyone who has voted so far - please keep them coming! Lurkers,
this means you!

In the interests of saving time, I propose that an additional thread start
soon, to determine choices for a decorator keyword, in the event that our
selected syntax requires one. Please visit the PythonDecorators Wiki page,
and navigate to section 6.1 Indicators (or follow this link
http://www.python.org/moin/PythonDec...8529997f56fc9e )
(not sure how reliable this is?) I have started numbering the options in
preparation for another voting thread, if you have other proposals, please
include them on this Wiki page, along with your +/0/- commentary.

Good plan. If anyone likes "wrap" they could add it to the Wiki with
something akin to the description of transform

David

[Paul McGuire]

"David Fraser" <da****@sjsoft.com> wrote in message
news:cg**********@ctb-nnrp2.saix.net...

Good plan. If anyone likes "wrap" they could add it to the Wiki with
something akin to the description of transform

David

David -

I encourage you to do this for yourself, if you have time. I think this is
exactly the kind of thing Wiki was intended for - we are all empowered to
include items on that list.

(If you do not see the "EditPage" option at the bottom of the page, select
the "Preferences" item on the left-side menu and enter your info. Once this
is done, you should be able to edit pages.)

-- Paul

[Paul McGuire]

"Paul McGuire" <pt***@austin.rr._bogus_.com> wrote in message
news:2C*****************@fe1.texas.rr.com...

(If you do not see the "EditPage" option at the bottom of the page, select
the "Preferences" item on the left-side menu and enter your info. Once this is done, you should be able to edit pages.)

Um, not sure I got that quite right. UserPreferences instructions can be
found at the top of the Wiki home page,
http://www.python.org/cgi-bin/moinmoin/FrontPage.

-- Paul

[Michael Sparks]

Paul McGuire wrote:

Please visit the PythonDecorators Wiki
page, and navigate to section 6.1 Indicators (or follow this link
http://www.python.org/moin/PythonDec...8529997f56fc9e )
(not sure how reliable this is?) I have started numbering the options
in preparation for another voting thread, if you have other proposals,
please include them on this Wiki page, along with your +/0/-
commentary.

A couple of comments I'd personally make...
* If you look at longer lists of decorators, what strikes me
personally is that any format is declaring properties of the
function that follows.

* It's worth considering is ability for people to search effectively
for what a piece of syntax means, especially if it's something not
likely to be heavily used by code. (Consider what happens if you
google for the phrase: to be or not to be)

For example would "properties" (not listed as an option) give any
indication that the function is being changed? "decorate" to a
greater extent does. "modifiers" or "decorators" (call a spade a
spade?) might be clearer, is just a noun.

A very useful way of dividing up decorators was posted a week or so
back, which formed the structure of section 6. Personally I think
something similar might be useful here:

* Use noun or verb
* If noun, singular or plural? (Sheep excepted)
* If verb, active or passive
* Hint at properties or actions
* Whether to link with the def or not.

"decorate" falls into the verb, passive, action category I think.
"modifiers" falls into the noun, plural, property category I think.
"using" would fall into verb, active, action, linked category

Personally I think noun, plural, property is a non-starter for most
situations (eg classmethod, staticmethod). There's probably similar
examples that work well.

Regards,
Michael.
--
Mi************@rd.bbc.co.uk
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.

[David Fraser]

Paul McGuire wrote:

"David Fraser" <da****@sjsoft.com> wrote in message
news:cg**********@ctb-nnrp2.saix.net...

Good plan. If anyone likes "wrap" they could add it to the Wiki with
something akin to the description of transform

David

David -

I encourage you to do this for yourself, if you have time. I think this is
exactly the kind of thing Wiki was intended for - we are all empowered to
include items on that list.

(If you do not see the "EditPage" option at the bottom of the page, select
the "Preferences" item on the left-side menu and enter your info. Once this
is done, you should be able to edit pages.)

OK you were right I was avoiding registering :-) ... done now

David

[Paul McGuire]

One impression I've gotten from this whole endeavor (even going back to
Kevin Smith's python-dev e-mail thread titled "PEP 318: Can't we all just
get along?") is that what started out as a desire to simplify the
designation of some methods as "class-level" or "static" or "special" in
some way, has gotten muddied with the implementation as it got represented
with the classmethod and staticmethod decorators, and then mutating to
accommodate all types of modifier/decorator/mutators, for resource locking,
debugging, logging, memoizing, etc.

Similarly, I feel our fixation on the "decorator" concept is confounded by
our own understanding that the entries in a list of decorators such as:

keyword:
memoize
synchronize
staticmethod
def foo:
pass

will translate to:
foo = staticmethod(synchronize(memoize(foo)))

in the current vernacular.

But should we consider this implementation detail when coming up with this
name? I'd prefer to think of the associations that exist between the
concepts of 'memoize' et al. with 'foo', and use a keyword that describes
those relationships. And try to do this independent of implementation, or
coincidence with a GoF archetype.

So I have been looking at some alternatives, such as
helper:
amend:
modify:
qualify: (or perhaps qual:)
property: (or perhaps prop:)

On an alternative path, does this have to be a real word? I confess that
"qual" strikes me in an interesting way, in that it could be thought to
represent either "qualifier" or "quality", and yet is neither. Or if
"lambda" is used, why not some other Greek letter, such as "mu" or "sigma".

Still, I would like to avoid arbitrary words, as they are little better than
'@' - I'd say that something like "gerbil" should be right out! :)

This clearly represents some "thinking out loud". Throw rocks or
suggestions at will.

-- Paul

[Michael Sparks]

Paul McGuire wrote:
....

Similarly, I feel our fixation on the "decorator" concept is
confounded by our own understanding that the entries in a list of
decorators such as: .... [ short list ] ... will translate to:
foo = staticmethod(synchronize(memoize(foo)))

in the current vernacular.

But should we consider this implementation detail when coming up with
this name?
Since they're a list of functions that will be applied to the
function/method that follows, I personally think it's important.

Whilst many decorators can be alluded to as a keyword, I don't think all
decorators would be. Consider how you would describe the actions of
this list, or how you would describe this list of actions: (taken from
various sources)

staticmethod
generator
grammarrule('statement : expression')
versioninfo("Added in 2.4")
deprecated
typeinfo(None)
author("joe bloggs")
funcattrs(grammar="'@' dotted_name [ '(' [arglist] ')' ]",
status="experimental", author="BDFL")
qualify: (or perhaps qual:)
property: (or perhaps prop:)
On an alternative path, does this have to be a real word? I confess
that "qual" strikes me in an interesting way, in that it could be
thought to represent either "qualifier" or "quality", and yet is
neither.
Personally I'd prefer a full word, but neither def or elif are full
words, so I doubt it _has_ to be, but I'd prefer something relevant to
what is happening behind the scenes rather than something ambiguous :)
Or if "lambda" is used, why not some other Greek letter, such as "mu"
or "sigma".
Because they're not really meaningful beyond a small number of people?
This clearly represents some "thinking out loud".

Ditto.

One other thing that jumped out at me is that different syntaxes
probably work better using different keywords. (Partly why I've snipped
decorator syntaxes)
Michael.
--
Mi************@rd.bbc.co.uk
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.

[Steven Bethard]

Michael Sparks <michaels <at> rd.bbc.co.uk> writes:

One other thing that jumped out at me is that different syntaxes
probably work better using different keywords. (Partly why I've snipped
decorator syntaxes)

Yeah, I noticed that pretty quickly too. It looks though, that, of the
suggestions requiring a keyword, only the J syntaxes are getting substantial
support. If it seems reasonable to others here, I think we should assume that
when we're discussing keyword options here, we're aiming at keywords for the J
syntaxes (and most probably J2).

Steve

[Neil Hodgson]

Michael Sparks:

Whilst many decorators can be alluded to as a keyword, I don't think all
decorators would be. Consider how you would describe the actions of
this list, or how you would describe this list of actions: (taken from
various sources)

staticmethod
generator
grammarrule('statement : expression')
versioninfo("Added in 2.4")
deprecated
typeinfo(None)
author("joe bloggs")
funcattrs(grammar="'@' dotted_name [ '(' [arglist] ')' ]",
status="experimental", author="BDFL")

Declarations?

declare:
staticmethod
versioninfo("Added in 2.4")
deprecated
def cheeseSketch():

Neil

[Paul McGuire]

Some other ideas:

imbue
endow
bestow
embellish
extend
accum
glom
confer

[John Lenton]

On Fri, Aug 20, 2004 at 10:34:30PM +0000, Paul McGuire wrote:

Some other ideas:

imbue
endow
bestow
embellish
extend
accum
glom
confer

why not 'pies', and then everybody's happy?

--
John Lenton (jo**@grulic.org.ar) -- Random fortune:
Don't relax! It's only your tension that's holding you together.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBJ4yigPqu395ykGsRApt9AJwIfQ8tJKyMOZjjv+4bGg +wSTvpXQCfdJhu
eaa01Oz5TbVlti0E8qRadP0=
=E9zF
-----END PGP SIGNATURE-----

[Martin DeMello]

Steven Bethard <st************@gmail.com> wrote:

Michael Sparks <michaels <at> rd.bbc.co.uk> writes:

One other thing that jumped out at me is that different syntaxes
probably work better using different keywords. (Partly why I've snipped
decorator syntaxes)

Yeah, I noticed that pretty quickly too. It looks though, that, of the
suggestions requiring a keyword, only the J syntaxes are getting substantial
support. If it seems reasonable to others here, I think we should assume that
when we're discussing keyword options here, we're aiming at keywords
for the J syntaxes (and most probably J2).

I liked 'as:' for J2, but since that's earmarked...

with, using, having, applying, declare

martin

[François Pinard]

[Paul McGuire]

Thanks to everyone who has voted so far - please keep them coming! Lurkers,
this means you!

OK! Here is my vote:

J2 J2 J2

It might look like not much nuanced, but the nuances I had disappeared
after the reduction of plausible winners, as shown with the current
tallies. My vote is merely to strengthen statistics a little more. :-)

--
François Pinard http://www.iro.umontreal.ca/~pinard