[Python-Dev] Re: metaclass and author are already decorators (original) (raw)

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 somecondition: def foo():somecode else: def foo():othercode - computed inheritance: if somecondition: 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