__name__ becoming read-write?

[Arthur]

On Tue, 24 Aug 2004 02:28:09 +1000, Anthony Baxter
<anthonybaxter at gmail.com> wrote:

>On Mon, 23 Aug 2004 15:58:26 GMT, Arthur <ajsiegel at optonline.com> wrote:
>> Of course I am curious as to why, and what would be involved, and
>> wrong,. with merging the local variable and the actual name for these
>> special syntax items.  It would seem to have merit on its own terms.
>> 
>> For example I had noticed to use string substition on a function doc I
>> needed to assign to __doc__ outside the function.
>
>How would you envisage this working? Look at the following code:
>
>def foo(arg):
>    __doc__ = "bingle!"
>    if arg < 0:
>        __doc__ = "bangle!"
>    if arg > 0:
>        __doc__ = "bongle!"
>
>Now, _before_ this code is run, what's foo.__doc__ supposed to be set
>to? Remember, at this point, the code has not been run. The local
>__doc__ has no value at this point.
>
>Special casing __doc__ (or __name__) so that assignments to a local
>like that inside a function assign magically to the function object is
>bad magic. It leads to confusion and poor coding. In general, inside a
>function, you don't have access to the function object itself[1]


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__.

Something in the general direction, I think, of where Paul Morrow's
instincts were going.

I like it.

And have no idea whether it is feasible.

Art