[Python-Dev] Re: __metaclass__ and __author__ are already decorators

[Paul Morrow]

Martin v. Löwis wrote:

> Paul Morrow wrote:
> 
>> That's a terrible way to 'think' about this kind of programming --- 
>> programming thru imperative mutation. 
> 
> 
> This is Pythonic. In Python, we don't have any declarations (well,
> perhaps except for global). Instead, everything in a module is
> executed, including class and def statements. This is an important
> property, as it allows:
> - conditional function definition:
>   if some_condition:
>     def foo():some_code
>   else:
>     def foo():other_code
> - computed inheritance:
>   if some_condition:
>     base = B1
>   else:
>     base = B2
> 
>   class D(base):
>     body
> - and more
> 
> Decorators extend this pattern.
> 

That pattern (conditional definitions) is a recipe for disaster, and you 
should not use it if it can be avoided.  It's always best to use a 
declarative solution whenever possible and not disturb the natural 
resolution mechanism.  What you show is possible in Python (gosh, what 
isn't), but it does not 'define' Python.  It's not a salient feature of 
Python.  So it is not Pythonic (IMO).

>> So regardless of what is going on under the hood, it's better to think 
>> of this technique as a function annotation --- something additionally 
>> stated in its description --- than something that we *do* to the 
>> function.
> 
> 
> No. It is best to simultaneously think of this as descriptive *and*
> imperative. I.e. for most purposes, it is sufficient to consider it
> descriptive, but one always needs to be aware when it is more correct
> to consider it imperative. For example, you have to understand that
> 
>   @foo
>   def bar():self
> 
> might cause bar *not* to be a function. This can only be understood
> if you don't think of decorators as kind of attribute.
> 

Another recipe for disaster.  If foo can change bar into something that 
is no longer a function, then you can create defects that are 
unacceptably hard to find.  Never use that pattern either, if there is a 
less 'fancy' alternative (and there almost always will be).


>> *When* a feature gets added/applied to a class/function shouldn't 
>> matter to the programmer.  We've screwed up if we make them think that 
>> hard. 
> 
> 
> Depends on the situation. In some cases, it does matter, and then the
> programmer needs to think hard. However, she can only succeed in that
> case if she is even *aware* that the declarative view on these things
> is a simplification.
> 

Using magic is a kind of declarative programming.  But note to all 
programmers: magic isn't really 'magic', there's actually an underlying 
mechanism making the magic happen.  You can alter the way magic works if 
you really, really, really need to.  But we encourage you to first see 
if there isn't a way to solve your problem that doesn't change the magic 
(so that others have a prayer of understanding what you're doing).

>> They should simply be able to state which features they want a 
>> class/function to have (as they can now with __metaclass__, __lt__, 
>> etc.), and the system makes sure they are there when the 
>> class/function is called.  It's magical, but its easy to think about.
> 
> 
> Yes, it works most of the time. If this simplification is wrong, it
> gets so terribly wrong that the programmer needs somebody else who
> really understands it solves the problem. To avoid that, we should not
> try to hide the semantics, but make it obvious - and simultaneously
> explain that in most cases, the simplification will serve fine.
> 

No, 'how' magic works (details of the innerworkings of the interpreter) 
isn't necessary for most programmers to understand (unless of course 
you're working on the interpreter or in some other way trying to extend 
the Python system).  They only need to know what each type of magic does 
and how to use it properly.  That needs to be thoroughly documented. 
But the implementation should only be of interest to the low-level 
developers of the Python system (with rare exceptions).


>> That should be irrelevant to the programmer.  It's magic.  
> 
> 
> No, no, no. In a well-designed programming language, there is no place
> for magic, in the sense that what really happens is deliberately hidden
> for nobody to find. Instead, people should *know* the inner workings.
> Many people know the inner workings of the current language, and they
> can easily extend their mental model to decorators.
> 

Well, define magic.  If you mean automatic behavior, then I strongly 
disagree. You need the system to do things automatically for you, 
otherwise you're writing in nothing more than assembly language.  What 
kind of magic are you referring to?