__name__ becoming read-write?

[Arthur]

On Tue, 24 Aug 2004 14:27:15 +1000, Anthony Baxter
<anthonybaxter at gmail.com> wrote:

>On Mon, 23 Aug 2004 23:17:25 GMT, Arthur <ajsiegel at optonline.com> wrote:
>> > "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.
>> 
>> I am thinking (and I think Paul is thinking) that we can say the same
>> thing, succintly, in a manner that has precedence in the language
>> 
>> Mine's a one-liner that does not totally relieve the magicians burden
>> to be - somwhere down the line -  a bit expressive
>
>I'm not _quite_ sure what it is you're asking for here, but it _seems_
>like you want to have two different blocks inside a def - the first is
>the meta-block, which contains docstrings and other magic attributes,
>while the second is the actual code body? Is this correct? If this is
>the case, I think it's _possible_ that in the future we might see
>something like this, for typing purposes. Maybe. I'm not sure. But if
>we do, I can't see any point _at_ _all_ to signifying magic things
>with arbitrary words surrounded with __under__ meaning 'under is a
>decorator'. While Python does use __foo__, the list of values for foo
>that are meaningful is well described and documented.

All I think I am looking for is proportionality.  The solution should
be proportional to the problem.  The current syntax is expressive in
the way that, I thought, was always considered to be fundamental to
the concept of Pythonic. 

What is happening is no more and no less than what is obvious from the
code to someone who may have never studied the Python documentation,
but who is simply generally literate.  

The problems identified with the current syntax is:

1) the placement of the transformative code under the function  -
leading to a purely hypothetical problem - I am not aware of any
reports of acutal issues arising - of a reader missing important
information related to the function.

2) burdensome amounts of typing when dealing with long function names.

If Python needs to apologize for being itself in the limited
circumstances that give rise to these conditions, perhaps it can be
done with a bit more - I don't know - dignity.  Which would involve
recognizing the issues as minor annoyances, and providing some limited
relief.

I am though concluding that , if anything, tmy own suggestion goes
further than it should.  No __under__ is necessary.  We have #comment
for the developer to commnicate anything he needs to communicate about
the function from within the function.

And in those cases where the developer's editor's cut and paste
facility are on the fritz and they are dealing with 70 letter function
names, you have given them a writeable __name__ attribute as another
weapon to solve their issue. 

No it won't solve everything. But then there isn't that much to be
solved.

The solution of fixing these limtied annoyances by redefining good
Python decoding style to include  and encourage magic declarations
that can only be meaningful to a studied Pythoneers, is totally out of
left field, IMO. 

The shifting sands have and will have their own costs. IMO, here those
costs are substantial.  The hundreds of arguments that have gone on
here on python-list, with Python explaining itself and defending
itself, will have to be restated.  Because the Zen no longer holds as
nearly as true, and there becomes little left to distinguish Python as
a programming apporach.

For those who think that Python's future is  - perhaps - *the* CLR
language, and that this kind of redefintion of the language is a
necessary step in the direction that will make that kind of thing
possible, I would say  - not in my shop.

Art

Art