RetroSearch Browse

Thu Aug 12 06:18:02 CEST 2004 · https://mail.python.org/pipermail/python-dev/2004-August/047682.html

On Wed, 11 Aug 2004 18:36:27 -0700
"Brett C." <bac at ocf.berkeley.edu> wrote:

> >>But then how are you supposed to do multiple decorators for the same method?
> > 
> > 
> > Put more than one of them in the same decorate block:
> > 
> > class ...
> > 
> >   decorate staticmethod, locksFile(arg1):
> > 
> >     def meth1(...)
> >       ...
> > 
> >     def meth2(...)
> >       ...
> 
> I still don't like it.  It feels like I am classifying my methods based 
> on the applied decorators instead of thinking of decorators as, well, 
> decorators of methods. 

True, it is whole 'nother pair o' dimes, a different way of looking at
it than has been discussed so far.  But by decorating a whole
indentation block, new ideas can surface beyond decorating methods.

An indentation based decoration syntax can implement quite a few new
features by decorating a whole block including, but not limited to,
methods inside that block. This could possible implement several PEPs
that are really their own subset of a generic block decoration syntax.
Consider the followign decoration blocks: 

  # PEP 319  (disclaimer: my PEP)

  def foo():

    # asynchronous code

    decorate synchronized:
      # sychronous code

    # back to async

  # PEP 310

  def foo():  # undecorated

    decorate with(expr):
      # acquired block

      def bar():   # decorated
        ...

    # released

  # PEP 316 (method inside)

    decorate inv(expr), pre(expr):
      # invariant expressions

      def foo():  # decorated method
	...   

(although I'm a little fuzzy on that last one)

Possible more, what about __future__ features?

  decorate nested_scopes:
    ...

that's a bit of a stretch, but the point is decorated blocks can
introduce different language features or semantics on a per-block basis,
explicitly.  

Imagine Guido decided nested scopes were a bad idea, and decided to get
in the time machine and change the __future__ so the feature would never
be in the language. Those who chose to go back to the __future__ would
have to stay there, leaving that brilliant turd of an import in all
their code.

Decorated blocks would allow you to experiment explicitly with new
language features or semantics without having to guarantee that they
will be in the __future__.  They never even need to be considered for
the __future__, and if they were, the decoration would then become a
noop.

> I feel methods are the major thing and 
> decorators are just extra fluff on them, not the other way around as 
> this syntax says to me. 
>
> Changing the indentation delineates scope and I 
> don't feel decorators truly represent a change in scope.

I'm no language lawyer, but do all changes in indentation represent
changes in scope?  What about if, for, while, try, etc?

To me, methods are not the "major thing", it's indentation. Of all the
other people I've met who have heard of Python but never used it, almost
all of them know nothing about the langauge but for these facts: it's
based on indentation and few people go back once they get a taste of it.

Decorators preceding a method definition on their own line is the first
thing in Python I can think of that breaks wide of Python's indentation
style, which is what has made me so uncomfortable with it from the
beginning.

-Michel

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-August/047682.html below:

[Python-Dev] An indentation-based approach to decorators (was Another aproach to decorators.)