__name__ becoming read-write?

[Arthur]

On Wed, 25 Aug 2004 01:26:30 +1000, Anthony Baxter
<anthonybaxter at gmail.com> wrote:

>On Tue, 24 Aug 2004 14:00:35 GMT, Arthur <ajsiegel at optonline.com> wrote:
>> But all at a cost.  I would be comforted to hear you say something
>> about the costs you perceive.  If you present it is all just a win,
>> it becomes too easy to challenge your assessment. So easy, that even
>> someone like myself can pull it off, at least to an extent - and at
>> least in my own judgement.
>
>_Any_ new feature has a cost - whether it is in the additional
>training needed, the potential for truly horrendous hacks, the
>backwards-incompatibility, or whatever else.

I appreciate you taking the time to respond.

>
>The additional training issue:
>    One of my internal measures for evaluating new decorator syntax
>options is that it be *obvious* that "this is something new". The
>various ideas of "doing something wacky with a list" or "a magic
>'decorate()' function" fail this test, for me. They're not obviously
>doing something new.

Or else, "this is something deep", and "we are violating the normal
rules of expressiveness, and know it".  

One argument presented with some vehemence against the pre-alpha2
syntax and in support of the new approach is that the old represented
unacceptable "action at a distance".  

But isn't that inherent in a transformation.  A trivial sense of
action at a distance might be solved with the new syntax.  Replaced by
a more profound sense of action at a distance.  Knowing that *my*
saying these kinds of things carries an implicit assertion that a
non-technical impression is valid.  Or worth hearing, anyway. 

The best precedence some of us find for all this  is __metaclass__. 

It spells "deep", it spells "on guard, rolled my own", it spells
"action at a distance" (where and what 'M' - the metaclass -  is, is
not something revelaed in the declaration itself) 

Again, that is a non-technical assessment.  Python as language, in the
more general sense of language.

But none of this is where we are very far off from one another,
anyway.  

>From the wioki list as it stands, I'm an A1 guy, after all.

>    Following on from that, the new feature should be explainable in
>the context of existing knowledge. 

For someone like myself, __something__ would do much of the explaining
in and of itself  There would be something visceral I understood,
before I understand anything else.

But I will let Paul continue to try to carry this torch.  It doesn't
look like he is getting too far, too fast.  

I always need to consider the fact that there are technical issues I
don't understand that override the the intuitive, and language, issues
I beleive that I do.  Certainly that seems to be your position on
__something__ inside the fucntion def. It sounds to my ears
unnecessarily, almost arbitrarily, purist.  But in the end this is not
something I am in a position to argue.  

>The before-def decorator syntax is

Without going on, I would say that I don't think *you* understand some
the depth of the problem here.  There is actually not yet a way to
talk about the mechanism which you are calling decorator syntax
because  of the fact that the lack of consensus runs that deep. Some
feel it is a misnomer on technical grounds and others consider it a
misnomer on the basis of being unexpressive and uninformative.  To
discuss "decorator syntax" is a concession. To meet on an even playing
field, we can only discuss The Mechanism.

Art