Are decorators really that different from metaclasses...

[Paul Morrow]

Jeff Shannon wrote:
> Arthur wrote:
> 
>> "Jeff Shannon" <jeff at ccvcorp.com> wrote in message
>> news:10jcsuh7k4bfl41 at corp.supernews.com...
>>  
>>
>>> (I'm sure that you'll argue that the presence of those "magic" variables
>>> is enough distinction between the two radically-different blocks of
>>> code; I'm also pretty confident that very few people will agree with
>>> you, and that nobody with a reasonable understanding of Python internals
>>> will be among those few people.)
>>>   
>>
>>
>> It seems to me if the defining distinction is a different assignment
>> operator rather than magic associated with naming, then much of 
>> objections I
>> am hearing to what Paul is generally suggesting seems to fall away.
>>
>> I like what Paul Rubin suggested for decorators:
>>
>> ::
>>
>> It seemed to me that many folks, and certainly including some 
>> sophisticated
>> users - witness the decorator wiki - felt more than comfortable with some
>> declarative/definitional syntax within the function body.  The discussion
>> was stalled mostly by the realization that Guido had definitively 
>> ruled it
>> out, not on the basis that there was general concensus that the 
>> approach had
>> no appeal - intuitive and otherwise.
>>  
>>
> 
> I agree with what Paul Rubin says there, as well.  However, I don't 
> believe that he was considering syntax that *looks* like 
> otherwise-ordinary assignment to "magic" names, which are indicated only 
> by naming convention.  Docstrings don't look like part of the function 
> body, because they don't look like otherwise-normal statements.  
> Suitably-indicated decorators (even @decorator) inside a def wouldn't 
> (IMO) look like part of the function body, because they too would not 
> look like otherwise-normal statements.  On the other hand, this "magic" 
> proposal of Mr. Morrow's *does* look like otherwise-normal statements -- 

I think that this "they look just like a normal statement" business 
needs to be examined.

To someone who has not seen Python before, an assignment to a magic 
variable does /not/ look the same as an assignment to a normal variable. 
  Of course they have similarities (they both have a name to the left of 
an equals sign, and an expression to the right), but the 
double-underscores surrounding the magic variable name represent a 
/huge/ syntactic difference between the two.  Assemble a random 
collection of 20 assignment statements --- half assigning to normal 
variables and half to magic variables --- and show them to a bunch of 
non-python developers.  I'd bet the majority will see two distinctively 
different syntactic structures; not just one.

And to someone who /does/ know Python, the difference is even greater. 
Because they not only see the different syntax, they are also aware of 
the different semantics.  So to the Python developer, there is an 
obvious difference on two levels (syntactic and semantic).

And speaking of the different semantics, we should remember that 
assigning to a magic variable is *never* a normal operation.  There are 
always consequences to doing so, magical consequences [*].  When we are 
reading someone's code and run across such an assignment, it would 
likely be a mistake to treat it as just another variable assignment.  It 
will (nearly) always be more than that.  That's probably why they (magic 
variable names) were given such an in-your-face, 
sticks-out-like-a-sore-thumb look.

So I believe that --- whether you're a pythonista or not --- assignments 
to magic variables really don't 'look' like normal statements.  They 
look like they do something special (because they do).

Paul


[*] Well, unless you count __author__ and __version__, which aren't 
really officially magic variables, although they are recognized by 
pydoc, so I guess there are even consequences to assigning to them.