[Python-Dev] Re: __metaclass__ and __author__ are already decorators
Paul Morrow
pm_mon at yahoo.com
Sun Aug 22 18:10:33 CEST 2004
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?
More information about the Python-Dev
mailing list