__name__ becoming read-write?

[Paul Morrow]

Anthony Baxter wrote:
> 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)
> 

No Anthony.  Please don't ever write doc strings like that.  Please...
I don't care what kind of technical problems that solves, that's not 
good looking code (IMO).

> 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

New users just need to learn that __anythingThatLooksLikeThis__ is 
probably magical; that care should be taken anytime they mess with 
variables so obviously and particularly 'decorated' (sorry :-)).  Of 
course experienced pythonistas already know that these things are 
special and that they (almost) never have the 'local variable' semantics 
they appear to have.  So it's an education problem; making new users 
aware of the consequences of manipulating magical attributes.

And yes, I've been suggesting that we do more with that syntax.  That we 
create magical attributes (or a single magical attribute) that change 
the behavior of functions, just as __metaclass__ changes the behavior of 
classes [*].  Hey, how about a __features__ attribute?

    def foo():
        __features__ = synchronized, memoized


* When I say "just as", I don't mean to indicate that the mechanics of 
the transformation are the same.

Paul