H
Hallvard B Furuseth
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.
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 keywordwhich 'gunzip's the rest of the source file before reading more of it.