[Python-Dev] Extended Function syntax

[David Goodger]

Guido van Rossum wrote:
> A while ago there was a proposal floating around to add an optional
> part to function/method definitions, that would replace the current
> clumsy classmethod etc. notation, and could be used for other purposes
> too.  I think the final proposal looked like this:
> 
>    def name(arg, ...) [expr, ...]:
>        ...body...
> 
> Does anyone remember or know where to find the thread where this
> proposal was discussed?

Some other interesting related posts:

- http://mail.python.org/pipermail/python-list/2001-July/056224.html
- http://mail.python.org/pipermail/python-list/2001-July/056416.html
- http://mail.python.org/pipermail/python-dev/2001-July/016287.html

> It ought to be turned into a PEP.

John Williams sent a very rough candidate PEP in October that was
interesting (below).  I sent back some suggestions (below the PEP), but I
haven't received anything back yet.  Perhaps a joint PEP with syntax
alternatives?

<pep>
PEP: XXX
Title: Multiword Method Names
Version: $Revision:$
Last-Modified: $Date: 2002/10/09 21:11:59 $
Author: John Williams <jrw@pobox.com>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 09-Oct-2002
Post-History:
Python-Version: 2.3


Abstract
========

This PEP proposes allowing the space character in method names.


Motivation
==========

With the addition of static and class methods to Python, there are now
three distinct kinds of methods.  All are declared using the same
syntax, and static and class methods are indicated by the use of the
built-in "wrapper" types staticmethod and classmethod.  This technique
is unfortunate because it requires two statements to define a single
method and requires the method name to appear three times.

These problems could be solved by allowing the space character in
method names and adding metaclass support for methods with certain
names, in effect allowing arbitrary pseudo-keywords to be added to
method declarations.


Specification
=============

The core of this proposal is to allow an arbitrary sequence of
identifiers and keywords to appear between the keyword "def" and the
opening parenthesis of the function declaration.  The result would be
identical to existing "def" statements, except that the name of the
new function would would consist of the words joined together with
space characters.  Although no syntax exists for working with
variables whose names contain spaces, the name would be accessible
through explicit use of the underlying variable dictionaries.

Using the new syntax along with special metaclass support, properties
and static and class methods could be declared like this::

    class MyClass(object):
        def class myClassMethod(cls): . . .
        def static myStaticMethod(): . . .
        def get myProperty(self): . . .
        def set myProperty(self, value): . . .

The declaration above would be equivalent to:

    class MyClass(object):
        def myClassMethod(cls): . . .
        myClassMethod = classmethod(myClassMethod)
        def myStaticMethod(): . . .
        myStaticMethod = staticmethod(myStaticMethod)
        def __getMyProperty(self): . . .
        def __setMyProperty(self, value): . . .
        myProperty = property(__getMyProperty, __setMyProperty)


Copyright
=========

This document has been placed in the public domain.
</pep>

Here's my reply to John:

<reply>
This PEP proposal is interesting, although the idea has come up before
(not a bad thing; see references below).  The first thing I notice is
that the title is misleading.  The title and abstract ("This PEP
proposes allowing the space character in method names") make me think
you're proposing that this kind of declaration would be legal and
somehow callable::

    def a multi word method name():
        pass

This would be too large a syntax change IMO. I think the "multiword"
aspect and "allowing spaces" are merely side-effects of what the PEP
is proposing.  They're implementation details.  The real issue is the
lack of a unifying syntax for descriptors.  The text of the PEP is
looking at the issue from the wrong direction IMO: from the bottom up
(implementation) instead of from the top down (concept).

I haven't wrapped my head around descriptors yet, and I'm not familiar
with Python's internals.  I have no idea if what you're proposing is
even feasible.  But here are some ideas and suggestions for the PEP:

* I think the PEP should be called "Syntax for Descriptors".  (I also
  thought of "Pseudo-Keywords in Method Declarations", but it's not as
  good a title.)

* Rather than "pseudo-keywords", what about calling these tokens
  "modifiers"?

* Perhaps metaclasses could grow a mechanism to add new
  pseudo-keywords of their own?  Maybe not right away.  When someone
  comes up with a novel use for descriptors, it would be nice to be
  able to implement it with syntax.

* Expand the examples to include the "delete" property method.  (I
  guess the modifier can't be "del", since that's already a bona-fide
  keyword.  But then again...)

* It may not be feasible to use "class" as a modifier, since it's
  already a keyword.  Perhaps "classmethod", as suggested in one of
  the threads below.

* Add some blanks to the examples to make them easier to read.

The same idea was brought up back in July 2001.  See the following threads:

- http://mail.python.org/pipermail/python-list/2001-July/056224.html

  (A reply from Guido:
  http://mail.python.org/pipermail/python-list/2001-July/056416.html)

- http://mail.python.org/pipermail/python-dev/2001-July/016287.html

There may have been other similar discussions.  Guido's reply is
discouraging, but he may have changed his mind since.  Having a PEP
clearly proposing the syntax change would be useful even if it's
rejected.

I would recommend you revise the PEP and send it to Python-Dev to
gather feedback before resubmitting it for a PEP number.
</reply>

--
David Goodger                    <http://starship.python.net/~goodger>
Python Enhancement Proposal (PEP) Editor <http://www.python.org/peps/>

(Please cc: all PEP correspondence to <peps@python.org>.)