pie-as-merely-syntax + decorator keyword

Hallvard B Furuseth h.b.furuseth at usit.uio.no
Sat Aug 28 14:05:49 EDT 2004


I haven't managed to catch up with all the decorator articles, but:

If we do get the pie syntax (or | or %% or whatever), is it too late
to get '@<keyword> staticmethod' and not just '@staticmethod'?

I've suggested it before, and I think others have too, but it seems to
have gotten lost in all the other discussion.

It's supposed to be a plus with the current pie syntax that the @
suggests something 'new' and non-obvious is going on.  I don't see it.

For one thing, it isn't going to remain new.  When we get something more
radically new, are we going to define it as '@$!!statement' to _really_
make it stand out?

For another, it _isn't_ new.  It's just new syntax for something old.
All that is new is that there is a new type of _syntax_: A new way to
express how statements affect each other; neither indentation nor
program flow.  It's not an _advantage_ of the pie syntax that it does
this, compared with most other proposals.  It's merely _necessary_ that
it does it, since it does not use other visual cues like indentation.

So if we get a pie, I think that's all the pie should mean:  'Abnormal
Syntax Alert'.  That could be a useful thing to have in the future, e.g.
for compiler directives, and it doesn't mix up two completely different
things:  An entirely new kind of Python syntax, and statements that
express normal execution of code.

Then follow it with a keyword which says that this particular abnormal
syntax applies decorators to the following function definition.

Other 'pie-keywords' could be added later at need; there would be less
worry about having used up an unused character.  Like, oh I don't know,
keywords that change the function they occur in so that it returns
something else than its return statement says.  Such a keyword would
_really_ need to stand out.  '@yield', for example:-)  Or a keyword
which 'gunzip's the rest of the source file before reading more of it.

-- 
Hallvard



More information about the Python-list mailing list