__name__ becoming read-write?

[Arthur]

On Tue, 24 Aug 2004 01:40:29 +1000, Anthony Baxter
<anthonybaxter at gmail.com> wrote:

>On Mon, 23 Aug 2004 14:07:42 GMT, Arthur <ajsiegel at optonline.com> wrote:
>> 
>> 
>> Did I hallucinate something about __name__ becoming read-write?
>
>> Better get my facts straight first....
>> 
>> But if true that would seem to solve the main objection to:
>
>> the_horrible_name_I _need_to_call=transform(__f)
>
>> And would mean that a byproduct of the PEP318 implementation would go
>> 50% toward obviating the need for a PEP318 implementation.  At least
>> by one measure.
>
>No, it is now read-write, thanks to mwh. I think, though, that you're
>misunderstanding the difference between setting a local variable in
>the function, called '__name__', and setting the actual __name__ of
>the function object.

You are right. I did know this to be *possibly* true, but had no
implementation to test.

Though  __doc__ (and I am sure other stuff) exhjibits the same
behavior, so there is no real excuse to be surprised.

This sabotages my approach, but only to the extent that we would still
need until after __f's def to know the name we are imposing on it.

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. 

Unless I was hallucinating.

Though I would understand if you are not in tutorial mood, or mode.

Art






>>>> def foo(): pass
>... 
>>>> foo.__name__ = 'bar'
>>>> foo.__name__
>'bar'
>>>> def foo():
>...   __name__ = 'bar'
>... 
>>>> foo.__name__
>'foo'
>>>> foo.func_code.co_names  
>('__name__',)