__name__ becoming read-write?

[Anthony Baxter]

On Mon, 23 Aug 2004 17:00:39 GMT, Arthur <ajsiegel at optonline.com> wrote:
> I see the point.
> 
> But.. there is always a but.
> 
> I'm thinking now a special sytnax item in the __form__ at the top of
> function that would:
> 
> 1) put one on notice that the function is to be transformed (as in
> "see below").
> 
> 2) allow a name to be assigned to it, which will become the
> transform's __name__.

This is a bad idea - code inside the function should be executed when
the function is executed. docstrings are a special-case (because
they're not actually code), but, to be honest, this whole discussion
has made me deeply uncomfortable with where the docstrings sit at the
moment. Once 2.4 is out, I know I'll probably start using something
like:

def doc(str):
    def endoculate(func, str=str):
        func.__doc__ = str
        return func

@doc('''This function frobulates the meta-whatsit''')
def frobulate(metawhatsit):
    .....

(insert final decorator syntax as required)

Paul Morrow's idea of special magic __foo__ inside the function is
deeply magical, and not likely to make any new users running across it
any happier. "So wait, this stuff that _looks_ like code in a
function, isn't actually? what the hell?" The new syntax[1] for
decorators is at least very obvious that something _new_ is going on.
This has been one of the things I've been using as an internal filter
for various syntax proposals for decorators. It should _not_ look like
some existing valid python that "just happens" to have a new effect.
I'd also prefer that the syntax _not_ be valid python in pre-2.4, in
case code accidently gets run under an old interpreter. The decorator
usage I have planned will be very very ugly if the decorators _don't_
get applied to the function, for whatever reason.

[1] whether @syntax, or block-before-def