PEP 318 - Function Modifier Syntax
ianb at colorstudy.com
Wed Jun 11 10:10:47 CEST 2003
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:
def foo(cls) as classmethod: ...
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:
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(object) as Meta: ...
is the same as:
__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.
More information about the Python-list