class Foo:
       """ This is the docstring for class Foo. """
       __metaclass__ = M
       # body of class goes here

    def baz():
       """ This is the docstring for function baz. """
       __features__ = synchronized, memoized
       # body of function goes here.

I personally find the above baz function aesthetically appealing.  Does
anyone else feel this way?  For contrast, below is the same function
written in the proposed A1 and J2 [*] syntaxes (respectively).

    @synchronized
    @memoized
    @doc(""" This is the docstring for function baz. """)
    def baz():
       # body of function goes here.

    decorate:
       """ This is the docstring for function baz. """
       synchronized
       memoized
    def baz():
       # body of function goes here.

* if J2 is accepted, the name 'decorate' may be replaced with some other
keyword, but I believe that the structure of the syntax would stay the same.

Obviously me,but it's possible doors are closed,too many heads try to
solve something that I start to think show a "bug" in python
architecture.I mean,does ruby need to throw up so much dust to add such
a feature?Or it just allow people to "build"  language syntaxes?

There seems to be an artificial deadline which is motivating the push to
implement something, even though the effect can already be achieved, in
a less desirable way, by placing the transformer aka decorator after the
function body.

I like the general thrust of this proposal - let's use existing
structures if this is possible.  The idea of putting the modifier
__features__ after the thing named and given a signature also makes sense.

I thought about using:

    class Foo:
       """ This is the docstring for class Foo. """
       __decorators__ = {'metaclass': 'M'}
       # body of class goes here

    def baz():
       """ This is the docstring for function baz. """
       __decorators__= {'features': ['synchronized', 'memoized'],
         'docstring':'This is the docstring for function baz. '}
       # body of function goes here.

This seems extendable (e.g. you can add keys to __decorators__
dictionary without disturbing existing keys) and "sort of"
parallels __dict__ which everyone understands.

Some of these discussions are so far over my head that I thought
my idea didn't somehow make any sense at all.  Then I saw your post.

Thanks,
Larry Bates
Syscon, Inc.

http://mail.python.org/pipermail/python-dev/2004-August/048176.html

That being said, I think the main objection to this syntax is the same
objection to any inside-def syntax:  The code inside a funcdef block (with the
exception of docstrings, which Guido has repeatedly said he regrets putting
there) is executed as part of the /execution/ of the function, not
the /definition/.

Note a classdef is not really the same in this respect.  The code inside a
classdef block is executed as part of the /definition/ of the class.  Compare
what happens when you call Foo() with what happens when you call baz().  With
the call to Foo(), you don't execute the code in the classdef block; you
execute the code in __new__ and/or __init__.  With the call to baz(), you /do/
execute the code in the funcdef block.

So the basic answer is that decorators are different from metaclasses because
the code inside the funcdef block is executed when the function is /called/,
while the code inside the classdef is executed when the class is /declared/.

It may be a subtle difference, but I believe this is what Guido disliked so
much about the inside-def syntaxes...

Class decorators are not in 2.4, because you can do most things you'd
do with a class decorator by using a metaclass, but in a completely
different way. In my opinion, class decorators _should_ be in 2.4,
because they're a much saner way to handle many things that require a
metaclass today.

They don't "alter the default behaviour". A metaclass allows the user
to specify an object that builds classes in a new way. A decorator
allows the user to specify a way to transform the already built
function (or class, for class decorators).

So, no, I for one like docstrings right where they are.  And look at
what they create a precedent for.

When Python executes a def statement, it binds __doc__ to the docstring
it finds there.  But what is __doc__?  It's an attribute of the method
or function object being defined.  Yep.  Its metadata.  It's information
*about* the method/function.  __doc__ is *not* a local variable of the
method or function object being defined.

I believe that (virtually) all __xxx__ attributes have this metadata
aspect (semantics) to them.  When a programmer says

    def foo():
        __author__ = 'Wilma Flintstone'
        __version__ = '0.1'

She does not intend for __author__ nor __version__ to be local variables
of foo, used somehow by foo in the calculation of its return value.  To
her they are foo /metadata/ --- attributes of the foo object itself ---
as they contain information that *describes* foo.

Likewise, when she defines __lt__, __getitem__, __init__, etc. as part
of a class, they will not typically be called by methods of the class or
users/consumers/clients of the class [*] the way that 'normal'
attributes will.  They contain meta info that describes a deeper level
of class behavior.

And so if all __xxx__ attributes are really metadata attributes, let's
formally recognize that.  Then, when processing a function/method def,
after Python binds __doc__ to the function's docstring, it can go ahead
and bind the other __xxx__ attributes too, making them function
attributes rather than local variables.  And then after it's finished
with the function def, if the function defined the __features__
attribute, Python can pass the completed function in turn to each
decorator in the __features__ tuple (or some such).

No asymmetry.  No new syntax.  No warts.

* well, __init__ is a little odd in this respect as subclasses will
sometimes call a parent's __init__ directly, but that's an exception.

class Identity:
    def get(self, x):
        return x
    __getitem__ = get

How is __getitem__ any more "metadata" then get is?  They provide exactly the
same functionality.  The __getitem__ declaration just allows you to access the
get method using "[...]".

Are you trying to say that "metadata" is the same thing as "operator shortcut"?

if you put the class def inside a function and dis.dis it, you get:

 >>> def foo():
 ...     class C(object):
 ...         __metaclass__ = MC
 ...         def m(self): return 'method m'
 ...     return C
 ...

Above we have *compiled* both foo and the class definition in its body, but we
have executed only the foo *definition*. (Note no complaint here about MC undefined)

 >>> import dis
 >>> dis.dis(foo)
   2           0 LOAD_CONST               1 ('C')
               3 LOAD_GLOBAL              0 (object)
               6 BUILD_TUPLE              1
               9 LOAD_CONST               2 (<code object C at 008FDF20, file "<stdin>", line 2>)

              12 MAKE_FUNCTION            0
              15 CALL_FUNCTION            0
              18 BUILD_CLASS
              19 STORE_FAST               0 (C)

   5          22 LOAD_FAST                0 (C)
              25 RETURN_VALUE
              26 LOAD_CONST               0 (None)
              29 RETURN_VALUE

Just to show when the class definition finishes:

 >>> def MC(*args): print args; return type(*args)
 ...

Now call foo to make the class *definition* in the body of foo execute (BTW triggering MC):

 >>> Cfoo = foo()
 ('C', (<type 'object'>,), {'m': <function m at 0x00903370>, '__module__': '__main__', '__metacla
 ss__': <function MC at 0x008FD4F0>})

(the printed args tuple above wrapped, obviously)

What we got:
 >>> Cfoo
 <class '__main__.C'>
 >>> Cfoo.m
 <unbound method C.m>
 >>> Cfoo().m
 <bound method C.m of <__main__.C object at 0x00901FD0>>

Is not time to put order in the possible uses of __xxx__ with a job on
classifying them and stop looking for a better role for BDFL?

Proposals:

1) Ban a "just because I'm free of doing it" use of them as
settable/gettable attributes (in place of  non special meanings attributes)
   (optional actually)

2)One or more builtin classes (interfaces)  useful to build their
significance,with a previous work on classifying possible levels of
interpreter instructioning:
        a) Syntactical level:
                _1) (re)defining operators code
                _2) ......
        b)  Allocational level:
                __init__,__new__,__metaclass__ ....????
        c)  Decorational:
                .........
        d) Globalish:
                __name__,....
        d)  Whatelsetional ......

Here's what PEP 8 (http://www.python.org/peps/pep-0008.html) has to say
about __xxx__ attributes:

       __double_leading_and_trailing_underscore__: "magic" objects or
       attributes that live in user-controlled namespaces,
       e.g. __init__, __import__ or __file__.  Sometimes these are
       defined by the user to trigger certain magic behavior
       (e.g. operator overloading); sometimes these are inserted by the
       infrastructure for its own use or for debugging purposes.  Since
       the infrastructure (loosely defined as the Python interpreter
       and the standard library) may decide to grow its list of magic
       attributes in future versions, user code should generally
       refrain from using this convention for its own use.  User code
       that aspires to become part of the infrastructure could combine
       this with a short prefix inside the underscores,
       e.g. __bobo_magic_attr__.

Here's a link that gives some examples of them:
http://cardboard.nu/blog/2003_09_18/module_level_magic_variables.html)

Sure veterans know that if it looks like a local variable definition,
then it is one.  But my point is that (IMO) they don't normally rely on
that aspect of __xxx__ variables.  You'll almost never see a function
that examines its own metadata in the computation of its result.

    ident = Identity()
    print "%(alpha)s, %(beta)s, %(gamma)s" % ident

If we were to have a conversation about this conversation, then we would
be having a "meta-conversation."  /metadata/ is data that describes
data.  metadata for a function would be data that describes the
function; data *about* the function as opposed to data *used by* the
function.  For example:

    def circumference(diameter):
       """ This is a docstring.  It's metadata for this function. """
       __author__ = 'Paul Morrow'      # more metadata
       pi = 3.14                       # not metadata
       return pi * diameter

    class Foo:
        __metaclass__ = M         # comment out for default behavior

Athony seems to consider the current placement of the doc string a
"bug".

So there is at least *something* here.

My sense is that you are trying to zero in on it, before Python
commits itself to a workaround.

It would be selling Guido short to think that we has not considered
all this.  

On the other hand, he has not communicated much about it - so it is
hard to know for sure.

So I wish you luck in the digging.

It's probably notable that I could write my example in two ways:

class Identity:
    def get(self, x):
        return x
    __getitem__ = get

class Identity:
    def __getitem__(self, x):
        return x
    get = __getitem__

I think I could agree that the use of things like __getitem__ can indicate
some metadata about the class, but I'd note that that is not all they do.  In
the example here, __getitem__ defines a function that can be used like any
other function.  At the same time, because it's *named* __getitem__, we get
some metadata about the function.

Using the same logic, I should expect that in something like:

def baz():
    __foo__ = "bar"
    # body of baz

__foo__ would be a string, and could be used like any other string.  At the
same time, because it was *named* __foo__, we would get some metadata about
the string.

So I guess my point is that, while the *name* might give us some metadata, I'm
not convinced that the *use* is in any sense metadata.

class supe(object):
    """this docstring is rarely frobnosticated"""
    def do_something_based_on_metadata():
        frobnosticate(self.__doc__)

class sub1(supe):
    """I am sub1"""

class sub2(supe):
    """I am sub2"""

Something like this could often be considered premature
objectification, but I've used it successfully.  Also, you'll notice
that these are classes rather than simple functions - I admit I've
never had a need to think about function metadata before.

However, I know that many people have a specific view of metadata and
don't really see how decorators fit in.  To be frank, I think pep318
shoehorned in metadata to pretend that there was a wider application
area for decoration than there really is.  The current quite minimal
support for metadata is sufficient for 99% of metadata use cases.  My
example has worked in Python for some time.  I know that decorators
would allow different behaviors to be arbitrarily assigned to various
pieces of metadata, but that doesn't seem like a big win for code
maintainability.  If anyone decided to support pep318 based solely on
a love of metadata, he made a mistake.

I'm intrigued by decorators anyway, and in no small part because it
seems that they should be able to completely replace metaclasses,
which are themselves totally unrelated to metadata.  In fact, that's
what at first prompted me to read a thread with the title, "Are
decorators really that different from metaclasses..."  Class
decorators wouldn't be so different from metaclasses, but J2 or even
@pie are much better syntaxes than the current metaclass syntax.

In another post in this thread Anthony Baxter said they were
different.  I'll respond directly to that post.

What differences are there?  There could be a running-time difference,
but who cares about class instantiation time?  Object instantiation
time is what matters.  Also, an object the class of which has
__metaclass__ set currently also has __metaclass__ set to the same
thing.  This seems like an ill-advised feature, through which
presumably you could do odd and unmaintainable things, although these
could also be done through __class__.__metaclass__.  It's also an
inaccurate feature - can a simple object be said to have a metaclass?
To what would this be set for a class whose metaclass had a metaclass?

using:
    metaclass_decorator(baz)
class foo(bar):
    a = 1
    def moo(self):
        pass

could cause something similar to the following:

foo = metaclass_decorator(baz)('foo', (<class '__main__.bar'>,), {'a':
1, 'moo': <function moo at 0x00879E70>, '__module__': '__main__'})

Granted, this is slightly different from what a function decorator
does.  But the difference probably won't be felt by those who use
class decorators.  Besides the mischief inherent in the introduction
of another namespace floating around behind the __metaclass__ variable
of normal objects, I don't see anything metaclasses can do that class
decorators couldn't.  Class decorators can be passed arguments to
control what function they return (see "baz" above), but this doesn't
seem like a major difference.  So, no, I don't think that class
decorators would be _that_ different from metaclasses.

Something like Zope3's Interfaces, which allow you to specify the
Interfaces that an object or class implements, are closer to metadata,
but note that even there, we've gone from an initial API of:

    class Foo:
        __implements__ = ( IFoo, )

to
    class Foo:
        implements(IFoo)

... moving away from the double-under form to a more readable and
useful form. The new form allows for far more powerful and useful
behaviour, such as inheritence of interfaces from base classes.
Twisted has also moved from using the former style to the latter.
These are two _very_ large bodies of code, with a lot of very clueful
people working on them - and they found that the magic double-under
name was inferior to an explicit call syntax.

def foo():
    __name__ = '%s_banana'%(__name__)

This is not a big change; quite the contrary...

The interpreter, when it is executing a def statement, after it binds
__doc__ to the docstring, would execute any assignments to __xxx__
attributes it finds immediately following the docstring (if present).  So

    def circumference(diameter):
        """ This is a docstring. """
        __author__ = 'Paul Morrow'
        pi = 3.14
        return pi * diameter

would be /exactly equivalent/ to

    def circumference(diameter):
        pi = 3.14
        return pi * diameter

    circumference.__doc__ =  """ This is a docstring. """
    circumference.__author__ = 'Paul Morrow'

See how simple?  In fact, isn't this just as simple --- or even simpler
-- than what would be require to implement J2 or A1?

And remember, the assumption here is that these assignments (to __xxx__
attributes) are a form of declarations /about the function/, just as
docstrings are now.  There's no need to support conditional declarations...

    def foo():
       """ I am a docstring. """
       __author__ = 'Morrow'

       # Just as there is no proper, 'definition time' way to
       # conditionally change a docstring, the code below
       # will generate an exception (at runtime).
       if 1:
          __version__ = '0.1'
       else:
          __version__ = '0.2'

Think of what I'm proposing here as just a convenience syntax.  We can
already do the same thing after (outsidef of) the function def as the
second circumference example above shows.