Using metaclasses to play with decorators.

Carl Banks imbosol at aerojockey.invalid
Wed Jun 16 18:22:19 CEST 2004


Michael Sparks wrote:
> By doing so I came to the viewpoint of why have __doc__ ? Why not have
> access to whatever the first object is - as far as this is practical? If
> it's a dict, so be it, if it's a string, so be it, but provide a uniform
> way of accessing. (eg func.__meta__ perhaps)


That would be a bit problematic.  Here's the main problem:

    def afunc():
        do_something()
        ...

Here, do_something() is an expression.  Is it the first object or not?
Well, it can't be.  Python won't call do_something() until afunc is
called, but to use it as a decorator, you need to know it's value when
the function is defined.

Changing Python so that it evaluates do_something() at runtime is
totally out of the question.  It would cause nearly infinite
confusion.


Therefore, do_something() cannot be the first object you speak of.
Only a Python object with built-in syntax (string, dict, list, tuple,
integer, etc.), is even feasable as a first-object decorator.

But this use is still a bit confusing.  Constant objects, like strings
and integers, are not suitable for use as decorators.  Collection
objects, like dicts, can have side effects when evaluated.  Are these
side effects to happen when you call the function, or just when you
define it?

In other words, if you want to use dict as "first object decorators",
you have to live with one of two undesirable possibilities: that side
effects intended for the decorator get evaluated every function call,
or that the "first object" has special semantics.  (A regular
docstring, OTOH, has no side effects, and a function using one doesn't
have any special semantics, so there is no issue with them.)


-- 
CARL BANKS                      http://www.aerojockey.com/software
"If you believe in yourself, drink your school, stay on drugs, and
don't do milk, you can get work." 
          -- Parody of Mr. T from a Robert Smigel Cartoon



More information about the Python-list mailing list