PEP 318 - Function Modifier Syntax

[Ian Bicking]

On Tue, 2003-06-10 at 19:47, Erik Max Francis wrote:
> > "Has" doesn't seem good, because it implies that the function has a
> > property (of being a classmethod or something), when in fact the
> > function is being replaced/wrapped.
> 
> A fair point.  So if you were able to choose any keyword for this task
> that you wished, which would you choose?

I think "as" is a perfectly good keyword, and no other suggestion I've
seen is better.  It reads well and it represents the underlying
implementation fairly well.  And "as" is already (kind of) a keyword, so
all the better.  It was an early suggestion, and a good one -- I don't
know why people are working it over so much.

There's other more interesting subtleties that should be discussed,
really.  Representation of properties and pre/post conditions, for
instance -- I think there's room for new ideas there.

Or issues with bugs like:

    class Super(object):
        def foo(cls) as classmethod: ...

    class Sub(Super):
        def foo(cls): ...

I can imagine that being an annoying bug to find, and an easy one to
make.  Or I don't know what this would do:

    class Foo(object):
        def bar(self) as classmethod, synchronized(lock): ...

If classmethod returns a descriptor, is synchronized going to know what
to do with it?  I suppose you'll just get a "TypeError: 'classmethod'
object is not callable" error, and you'll figure it out from there.

I also find some of the ideas of generalizing this further to be of
interest, like maybe:

    def X as type: ...

is the same as:

    class X:

Or:

    class X(object) as Meta: ...

is the same as:

    class X:
        __metaclass__ = Meta

Or some of the other ideas that were on python-dev, where def blocks
became a sort of generalized code block.  I've forgotten the details,
but they were interesting when I was reading them ;)... that's probably
because I only partly understood the motivations. 

  Ian