At 11:35 AM 2/26/04 -0500, Jewett, Jim J wrote:

Pete Shinners:

...

Some of these may even be bad ideas apon further thought, but it's something to ponder.

Also, many of them don't work with the proposed syntax. Specifically, you're trying to provide a second binding for the function (such as running for __main__, or registering with the exit handler).

def __main__(func): if __name__=='__main__': func() This now works correctly as long as you define your main function as the last thing in your module. As for the exit handler thing, that works okay too. All that happens is that the function you decorate it as will be None. So after: def exitHandler() [atexit.register]: ... 'exitHandler' will be 'None', but the function as it was defined will be registered for running at system exit. So, yes, actually, these two ideas do work with the proposed syntax.

Features which are used frequently need to be short. Features which are used rarely (like this one?) can be more verbose.

Actually, I think that if the feature exists, it will be used frequently and for a wide variety of things. It is probably the closest thing to having macros that Python will ever get. We don't even know how many other cool things people will come up with to do with them.

I agree that if only advanced users will need it, then it can be a bit more complex to use.

Advanced users will *create* decorators, but everybody will want to *use* them.

If you use bare syntax, then the burden is on everyone, and you have raised the barrier to entry for the rest of the language.

I don't think that's true, even for the [] syntax case. Most decorator lists will be relatively short, and the items *in* the decorator list will almost always be a good place to look them up. It's only the reuse of non-decorators (like 'atexit.register') or undocumented custom decorators that's likely to be confusing in reading code.