Rather than decorators, how about sections?

[Paul Morrow]

I like many am not wild about the <at> operator. I also don't think
that the decorator syntax should be so directly attached to the method,
since what we're trying to do is to say something about the
*relationship between* a method and a class (e.g. "method m is a
staticmethod of class C").

So if we are going to extend the Python grammar to support this sort of
thing (which I believe is a good idea), my preference would be to
introduce named sections within a class definition, such as...

class Foo(object):
staticmethods:
def baz(a,b):
print "I'm a static method."
def bez(c,d):
print "I'm a static method too."

classmethods:
def biz(klass):
print "I'm a class method."


def __init__(self):
print "We all know what I am."

 

[Paul McGuire]

I like many am not wild about the <at> operator. I also don't think
that the decorator syntax should be so directly attached to the method,
since what we're trying to do is to say something about the
*relationship between* a method and a class (e.g. "method m is a
staticmethod of class C").

So if we are going to extend the Python grammar to support this sort of
thing (which I believe is a good idea), my preference would be to
introduce named sections within a class definition, such as...

class Foo(object):
staticmethods:
def baz(a,b):
print "I'm a static method."
def bez(c,d):
print "I'm a static method too."

classmethods:
def biz(klass):
print "I'm a class method."


def __init__(self):
print "We all know what I am."

This only addresses the "decoration" for declaring static and class methods.
The decorator mechanism is intended to include much more than this simple
class declaration feature. See
http://www.python.org/cgi-bin/moinmoin/PythonDecoratorLibrary for the first
application (memoize - a return value cacheing helper/decorator, to optimize
access to repetitive or compute-intensive function calls, with NO changes
needed to the function itself). Other decorator candidates I've seen
mentioned are:
- mutex lock/unlock wrapper
- debugging/logging wrapper
- pre-condition/post-condition assertion wrappers
- input argument validation/typing wrapper
- return value type validation wrapper

For this degree of flexibility, you can't hard-wire in specific section
names.

-- Paul

 

[Paul Morrow]

This only addresses the "decoration" for declaring static and class methods.
The decorator mechanism is intended to include much more than this simple
class declaration feature. See
http://www.python.org/cgi-bin/moinmoin/PythonDecoratorLibrary for the first
application (memoize - a return value cacheing helper/decorator, to optimize
access to repetitive or compute-intensive function calls, with NO changes
needed to the function itself). Other decorator candidates I've seen
mentioned are:
- mutex lock/unlock wrapper
- debugging/logging wrapper
- pre-condition/post-condition assertion wrappers
- input argument validation/typing wrapper
- return value type validation wrapper

For this degree of flexibility, you can't hard-wire in specific section
names.

-- Paul

I agree. My proposal wasn't looking at the bigger picture here. But
see the post by Stepfan Eischet in this thread. It doesn't address all
of those issues either, but it does make the bigger problem smaller, by
using an obvious interpretation of the method arguments to infer the
type of method (i.e. class -versus- static -versus- instance). By using
this simple convention (that most everyone is probably using already),
that aspect of the annotations require no additional syntax.

Hmmm... did I say 'aspect'? Maybe instead of cluttering up the code
with all of these 'declarations' (which is clearly where the decoration
movement is headed), we should have some sort of companion file that
contains these annotations, similar to what you see in the AOP languages.

 

[Paul Morrow]

This only addresses the "decoration" for declaring static and class methods.
The decorator mechanism is intended to include much more than this simple
class declaration feature. See
http://www.python.org/cgi-bin/moinmoin/PythonDecoratorLibrary for the first
application (memoize - a return value cacheing helper/decorator, to optimize
access to repetitive or compute-intensive function calls, with NO changes
needed to the function itself). Other decorator candidates I've seen
mentioned are:
- mutex lock/unlock wrapper
- debugging/logging wrapper
- pre-condition/post-condition assertion wrappers
- input argument validation/typing wrapper
- return value type validation wrapper > needed to the function itself).

memoize is an example of something that probably should not be specified
in the method definition. It's strictly a 'pragma' --- just a
suggestion to the compiler on how it could speed up the function. That
kind of 'decoration' (as well as some of the other examples you cited)
is of a 2nd class nature in that it doesn't affect whether the program
produces the correct result or not. Therefore, I would not want to have
such statements comingled with the statements that truly are germane to
the correct functioning of my code. They would only be a distraction,
and are best relegated to some other place in the code-base (another
file perhaps).

That's kindof the thinking behind aspect oriented programming (AOP). A
body of code should deal with only one aspect of the problem...

 

[Josef Dalcolmo]

May I point out that the term "static" comes from its use in a particular language and is used for two semantically different purposes. I don't think the word reveals the meaning very well. I strongly suggest to use a different term, that describes better what it does.

some ideas:

instance - class
noninheritable - inheritable
specific - generic
this - all
(self, var) - (-, var)

- Josef

 

[Steve]

class Foo(object):
staticmethods:
def baz(a,b):
print "I'm a static method."
def bez(c,d):
print "I'm a static method too."

classmethods:
def biz(klass):
print "I'm a class method."


def __init__(self):
print "We all know what I am."

I don't.

Is there a simple primer for static and class methods
and decorators and such that you can recommend?

I've looked at the URL you gave with the Memoize class
http://www.python.org/cgi-bin/moinmoin/PythonDecoratorLibrary,
but it assumes you already know what decorators are.

> Fine, instead of Foo (the name of the class), use

the > word klass. It's a popular name for the first

> parameter of a class method.

"klass" isn't a word. It is a twee deliberate
mispelling of a word.

It also runs the risk of causing confusion when code is
spoken aloud (eg in actual human-to-human communication
using alternating high and low pressure atmospheric
waves to deliver packets of information, or in text
readers for the blind).

It is bad enough when coders (including myself) choose
to deliberately mispell words, but to make it required
is unforgivable.

 

[John Roth]

Is there a simple primer for static and class methods
and decorators and such that you can recommend?

It's cleverly hidden on the Python documentation
page, under "additional documentation."

http://www.python.org/doc/newstyle.html

At some point all of this should be integrated into
the standard documentation, but that task has been
hanging fire since 2.2.

John Roth

 

[Richard Hanson]

[Bystander delurking -- idle musings...]

[Paul Morrow wrote:]

Hmmm... did I say 'aspect'? Maybe instead of cluttering up the code
with all of these 'declarations' (which is clearly where the decoration
movement is headed), we should have some sort of companion file that
contains these annotations, similar to what you see in the AOP languages.

Splork!

-- And just yesterday, continuing to note all the discussion in
py-dev (and here) involving just where in the *linear* layout of
the code the decorators should go, I thought that maybe we need
tables -- two-dimensional coding (orthogonal beats flat)...?

1) A column of cells (of lines, blocks?) for what we now use as
our single, linear arrangement (lines) of code.

2) A column of cells for decorators and the like -- decorators
would go in the cells alongside the decorated code.

3) Perhaps a column for source code documentation.

4) [...]

(Of course, then we'd need new editors, etc.)

;-)

thinking-laterally-y'rs,
Richard

 

[Paul Morrow]

It's a popular name for the first

"klass" isn't a word. It is a twee deliberate mispelling of a word.

It also runs the risk of causing confusion when code is spoken aloud (eg
in actual human-to-human communication using alternating high and low
pressure atmospheric waves to deliver packets of information, or in text
readers for the blind).

It is bad enough when coders (including myself) choose to deliberately
mispell words, but to make it required is unforgivable.

Ok I believe that's one vote against 'klass' as a reserved word

Then let it be 'cls', which is also popular. Or heck, to be flexible,
let it be something you can specify (as an environment variable,
compiler setting, etc.). The important point is that we should resist
changes to the language that require that the developer specify things
that are already clearly inferred thru the form/structure of his/her
code. We don't have to specify (with curly braces or whatever) where
code blocks start and end, because the form of our code tells us that.
It seems natural (to me, and at least one other person) to let the form
of a function's formal parameter list designate the type of function:

- if the 1st parameter is named 'self', it's an instance method.
- if the 1st parameter is 'cls' (or perhaps some suitable synonym),
it's a class method.
- for all other parameter arrangements, including no parameters, it's
a static method.

Simple, clear, obvious, intuitive, and I'm sorry, but this is the least
ugly of all the alternatives. There is nothing beautiful about at
signs, superflous code, clutter...