PEP 318: Can't we all just get along?

[Kevin Smith]

For what it's worth, I wrote the original PEP 318. I probably wasn't
qualified, but I just wanted a nice simple way to declare class methods
without having to repeat the function name. After submitting it to BDFL
for approval, more work was needed and the discussion of PEP 318 on
python-dev increased rapidly. It was evident that I was in over my head,
so I asked more someone more experienced to take over.

I guess others had bigger plans for my proposal that I had planned. It
has turned into the "solution" to many problems: type checking (both
arguments and returned values), metaclasses, metadata, interfaces,
function attributes, etc.). Unfortunately, in the process, this simple
request for syntactical sugar has turned into a monstrosity. In my
opinion, none of the proposed syntaxes really seem Pythonic. This PEP
just seems to be trying to solve too many problems.

Bear with me, but I'd like to propose one more syntax that is simple,
easy for newbies to understand, and nowhere near as powerful as the
current PEP's syntax. However, it doesn't add incoherent, arbitrary
syntax either.

def classmethod foo(x, y, z):
pass

That's it. One "decorator" that is a callable object that takes a
method as it's only argument. No expressions, lists, tuples, etc. Just
one callable object. Ok, if you absolutely must have more than one.

def classmethod synchronized foo(x, y, z):
pass

Once again, no expressions. I know that this isn't going to solve
everyone's type-checking, metadata, and function attribute problems, but
let's face it, using this PEP for all of those things just creates ugly
syntax. There must be more Pythonic ways to do those things in their
own PEPs.

--
Kevin Smith
Ke*********@sas .com

[Paul Morrow]

Kevin Smith wrote:

For what it's worth, I wrote the original PEP 318. I probably wasn't
qualified, but I just wanted a nice simple way to declare class methods
without having to repeat the function name. After submitting it to BDFL
for approval, more work was needed and the discussion of PEP 318 on
python-dev increased rapidly. It was evident that I was in over my head,
so I asked more someone more experienced to take over.

I guess others had bigger plans for my proposal that I had planned. It
has turned into the "solution" to many problems: type checking (both
arguments and returned values), metaclasses, metadata, interfaces,
function attributes, etc.). Unfortunately, in the process, this simple
request for syntactical sugar has turned into a monstrosity. In my
opinion, none of the proposed syntaxes really seem Pythonic. This PEP
just seems to be trying to solve too many problems.

Bear with me, but I'd like to propose one more syntax that is simple,
easy for newbies to understand, and nowhere near as powerful as the
current PEP's syntax. However, it doesn't add incoherent, arbitrary
syntax either.

def classmethod foo(x, y, z):
pass

That's it. One "decorator" that is a callable object that takes a
method as it's only argument. No expressions, lists, tuples, etc. Just
one callable object. Ok, if you absolutely must have more than one.

def classmethod synchronized foo(x, y, z):
pass

Once again, no expressions. I know that this isn't going to solve
everyone's type-checking, metadata, and function attribute problems, but
let's face it, using this PEP for all of those things just creates ugly
syntax. There must be more Pythonic ways to do those things in their
own PEPs.

Nope. That's using static declarations. We're a dynamically typed
language as much as possible. Isn't there something that doesn't
require any additional grammar words to identify classmethods and
staticmethods? Isn't there something, inherent in the way static,
class, and instance methods 'look' naturally, that would tell us what
they are?

[Peter Hansen]

Paul Morrow wrote:

Kevin Smith wrote:

def classmethod foo(x, y, z):
pass

That's it. One "decorator" that is a callable object that takes a
method as it's only argument. No expressions, lists, tuples, etc.
Just one callable object.

Nope. That's using static declarations. We're a dynamically typed
language as much as possible. Isn't there something that doesn't
require any additional grammar words to identify classmethods and
staticmethods?

It looks to me as though Kevin is not suggesting keywords, but
callables. In other words he would consider this valid, provided
my_own_decorato r was a callable.

def my_own_decorato r foo(x, y, z):
pass
-Peter

[Paul Morrow]

Peter Hansen wrote:

Paul Morrow wrote:

Kevin Smith wrote:

def classmethod foo(x, y, z):
pass

That's it. One "decorator" that is a callable object that takes a
method as it's only argument. No expressions, lists, tuples, etc.
Just one callable object.

Nope. That's using static declarations. We're a dynamically typed
language as much as possible. Isn't there something that doesn't
require any additional grammar words to identify classmethods and
staticmethods?

It looks to me as though Kevin is not suggesting keywords, but
callables. In other words he would consider this valid, provided
my_own_decorato r was a callable.

def my_own_decorato r foo(x, y, z):
pass
-Peter

Oh, sorry, I wasn't reading that closely enough. Hmmmm... it's an
interesting idea. It's not ugly...

First though, I still believe that we should exploit existing
conventions (recommended coding practices) as a way of getting 'free'
declarations for class, static, and instance methods (e.g. methods whose
first param is 'self' are instance methods, etc.). That feels very
pythonic to me, just as we use naming conventions to distinguish public,
private, and semi-private methods.

But I think that, where we want to provide additional info about a
method, and there are no conventions to take advantage of, Kevin's
suggestion does have some appeal.

Questions (for Kevin):

1. Would

def deco1 foo(a, b, c): pass

be the same as (just syntactic sugar for)

def foo(a, b, c): pass
foo = deco1(foo)

or would it mean something else?

2. Would

def deco1 deco2 foo(a, b, c): pass

be the same as

def foo(a, b, c): pass
foo = deco1(deco2(foo ))

or

def foo(a, b, c): pass
foo = deco2(deco1(foo ))
3. Would there be any restrictions on what a decorator could *do* to the
method it was passed? e.g. Could it change:

* the method's name (which could of course affect the method's
visibility: public|private| semi-private)?
* whether the method was a static, class, or instance method?
* the method's signature (formal parameter names, parameter order,
defaults values)?

[Michael J. Fromberger]

In article <20************ ********@braebu rn.themorgue.or g>,
Kevin Smith <Ke*********@sa s.com> wrote:

Bear with me, but I'd like to propose one more syntax that is simple,
easy for newbies to understand, and nowhere near as powerful as the
current PEP's syntax. However, it doesn't add incoherent, arbitrary
syntax either.

def classmethod foo(x, y, z):
pass

That's it. One "decorator" that is a callable object that takes a
method as it's only argument. No expressions, lists, tuples, etc. Just
one callable object. Ok, if you absolutely must have more than one.

def classmethod synchronized foo(x, y, z):
pass

Once again, no expressions. I know that this isn't going to solve
everyone's type-checking, metadata, and function attribute problems, but
let's face it, using this PEP for all of those things just creates ugly
syntax. There must be more Pythonic ways to do those things in their
own PEPs.

Kevin,

+1 for this idea.

I completely agree that the original PEP-318 proposed a simple and
reasonable idea, and I too have been much dismayed by all that seems to
have been grafted onto it since. This latest idea of yours certainly
sounds a lot more reasonable than anything else I've seen so far. It
solves the original well-defined problem cleanly, and probably solves
some of the other proposed uses too.

I would even go so far as to say: Go ahead and restrict it to at most
one callable object. If someone really wants to define a flaming hot
crossed synchronized blue classmethod foo, they can bloody well define a
callable object that has the (in)appropriate behaviour.

I hope that perhaps cooler heads (such as yours) will prevail, and keep
Python's syntax and semantics relatively neat and tidy. We don't need
the One PEP to Rule Them All, in the Land of Python where the shadows --
so far -- do not lie.

-M, "one more PEP out of you, mister, and you're history!" ;)

--
Michael J. Fromberger | Lecturer, Dept. of Computer Science
http://www.dartmouth.edu/~sting/ | Dartmouth College, Hanover, NH, USA

[Doug Holton]

Michael J. Fromberger wrote:

In article <20************ ********@braebu rn.themorgue.or g>,
Kevin Smith <Ke*********@sa s.com> wrote:

Bear with me, but I'd like to propose one more syntax that is simple,
easy for newbies to understand, and nowhere near as powerful as the
current PEP's syntax. However, it doesn't add incoherent, arbitrary
syntax either.

def classmethod foo(x, y, z):
pass

That's it. One "decorator" that is a callable object that takes a
method as it's only argument. No expressions, lists, tuples, etc. Just
one callable object. Ok, if you absolutely must have more than one.

def classmethod synchronized foo(x, y, z):
pass

Once again, no expressions. I know that this isn't going to solve
everyone's type-checking, metadata, and function attribute problems, but
let's face it, using this PEP for all of those things just creates ugly
syntax. There must be more Pythonic ways to do those things in their
own PEPs.

Kevin,

+1 for this idea.

I posted the same thing to python-dev (although it took a week for the
post to appear) and some guy said -infinity or something smart like that.
I think it is simpler to use keywords for classmethod and staticmethod
at least. Those are builtin features of python, just like they are
builtins for java (which has keywords for its builtins like static,
abstract, interface, etc.).
I propose this *in addition* to whatever decorator syntax we add. We
shouldn't consider staticmethod and classmethod as decorators.

[Bruno Desthuilliers]

Kevin Smith wrote:

For what it's worth, I wrote the original PEP 318. I probably wasn't
qualified, but I just wanted a nice simple way to declare class methods
without having to repeat the function name. After submitting it to BDFL
for approval, more work was needed and the discussion of PEP 318 on
python-dev increased rapidly. It was evident that I was in over my head,
so I asked more someone more experienced to take over.

I guess others had bigger plans for my proposal that I had planned. It
has turned into the "solution" to many problems: type checking (both
arguments and returned values), metaclasses, metadata, interfaces,
function attributes, etc.). Unfortunately, in the process, this simple
request for syntactical sugar has turned into a monstrosity. In my
opinion, none of the proposed syntaxes really seem Pythonic. This PEP
just seems to be trying to solve too many problems.

Bear with me, but I'd like to propose one more syntax that is simple,
easy for newbies to understand, and nowhere near as powerful as the
current PEP's syntax. However, it doesn't add incoherent, arbitrary
syntax either.

def classmethod foo(x, y, z):
pass

That's it. One "decorator" that is a callable object that takes a
method as it's only argument. No expressions, lists, tuples, etc. Just
one callable object.
+2 for me.

Ok, if you absolutely must have more than one.
def classmethod synchronized foo(x, y, z):
pass

No. If you want more than one, provide your own decorator, ie :

def synchronizedCla ssmethod(method ):
return synchronized(cl assmethod(metho d))

def synchronizedCla ssmethod foo(x, y, z):
pass

My 2 eurocents
Bruno

[Dan Sommers]

On Tue, 17 Aug 2004 21:13:47 -0400,
Paul Morrow <pm****@yahoo.c om> wrote:

First though, I still believe that we should exploit existing
conventions (recommended coding practices) as a way of getting 'free'
declarations for class, static, and instance methods (e.g. methods
whose first param is 'self' are instance methods, etc.). That feels
very pythonic to me, just as we use naming conventions to distinguish
public, private, and semi-private methods.

I don't understand how assigning semantic significance to a "recommende d
coding practice" is Pythonic.

In the face of ambiguity, refuse to guess.

Explicit is better than implicit.

I think that the idea that started this thread is just right:

def decorator function( arguments ): pass

is exactly equivalent to

def function( arguments ): pass
decorator( function )

Note that:

- the decorator is right next to the function name
- the decorator is outside the code of the function
- there are no new keywords or punctuation
- it's dynamic, flexible, and extensible

It's also abusable, but that's the nature of a language as dynamic as
Python.

Regards,
Dan

--
Dan Sommers
<http://www.tombstoneze ro.net/dan/>
Never play leapfrog with a unicorn.

[Paul Morrow]

Dan Sommers wrote:

On Tue, 17 Aug 2004 21:13:47 -0400,
Paul Morrow <pm****@yahoo.c om> wrote:

First though, I still believe that we should exploit existing
conventions (recommended coding practices) as a way of getting 'free'
declaration s for class, static, and instance methods (e.g. methods
whose first param is 'self' are instance methods, etc.). That feels
very pythonic to me, just as we use naming conventions to distinguish
public, private, and semi-private methods.

I don't understand how assigning semantic significance to a "recommende d
coding practice" is Pythonic.

In the face of ambiguity, refuse to guess.

Explicit is better than implicit.

Good conventions prevent ambiguity.

class Foo:
def method1(self, a, b): pass # clearly an instance method
def method2(cls, a, b): pass # clearly a class method
def method3(a, b): pass # clearly a static method
When declarations conflict with conventions, it makes us wonder what the
author really intended.

def staticmethod setX(self, x):
self.x = x

I think that the idea that started this thread is just right:

You're right, this thread is about decorators, not about more
opportunities for dynamic typing. I just wanted to remind us that
decorators are a lot like static typing, which isn't terribly pythonic.

[Kevin Smith]

In <ma************ *************** ***********@pyt hon.org> Paul Morrow
wrote:

Peter Hansen wrote:

Questions (for Kevin):
1. Would

def deco1 foo(a, b, c): pass

be the same as (just syntactic sugar for)

def foo(a, b, c): pass
foo = deco1(foo)

or would it mean something else?

Sorry, I guess I should have put the equivalent current Python code in
my first post. The example above is exactly what I meant.

2. Would

def deco1 deco2 foo(a, b, c): pass

be the same as

def foo(a, b, c): pass
foo = deco1(deco2(foo ))

or

def foo(a, b, c): pass
foo = deco2(deco1(foo ))
I would choose the first option since it's easier to transform the
string "deco1 deco2 foo" to "deco1(deco2(fo o))" while I'm reading it (i.
e. it fits my head :) ).

3. Would there be any restrictions on what a decorator could *do* to
the method it was passed? e.g. Could it change:

* the method's name (which could of course affect the method's
visibility: public|private| semi-private)?
Nope, beginners wouldn't understand it immediately. That's just too
magical.
* whether the method was a static, class, or instance method?
Yes.
* the method's signature (formal parameter names, parameter order,
defaults values)?

I guess, in theory, it could since the object returned by the
"decorator" (I really hate that term) could return a completely
different object, but I wouldn't suggest it.

--
Kevin Smith
Ke*********@sas .com