PEP318 alternate syntax idea

[Stephen Horne]

I seem to have written more than I intended below.

Whether the repetition of decorators will be a real issue is, of
course, undecided. Maybe the idea anticipates a problem which will
never be important anyway.

What I mean to say is that, if the following reads like I'm upset or
on the attack or something, I'm not. Sometimes, when I'm just trying
to be clear what I'm saying, I actually get very verbose and very
unclear, and too often I get right up peoples noses. Especially when
I'm stressed out for other reasons, as is definitely the case right
now.

I hope this isn't _too_ bad...


On 23 Mar 2004 11:39:05 -0800, JimJJewett at yahoo.com (Jim Jewett)
wrote:

>In python, 
>
>    block_starter:
>        indented_code1
>        indented_code2
>
>implies something about the how the *indented* code will be run.
>It may get skipped (if/else), repeated (for/while) or delayed
>(class, def), but it will definately do something strange.
>
>With decorators, the function definition itself is normal (and
>therefore should not be indented); it is the decorators that
>run at an unexpected time.

First off, indented blocks work in a very similar way to each other in
Python simply because of convenience - Python is a dynamic language
and can thus do many things with imperitive code that static languages
cannot.

But that doesn't mean there is a fundamental principle at work here.
In terms that an evolutionary theorist might used, this pattern is a
spandrel - an indirect and accidental consequence of something else.
The principle is that 'dynamic is good', which says nothing at all
about the meaning of indented blocks.

In programming in general, indented block structures serve a range of
purposes, many of them having nothing to do with how code is executed.
Member declarations in a statically typed language, for instance, are
not executed at all because they are not imperitive code. If it is
useful to group a range of things together for any purpose, an
indented block is very often the means of doing it. The indentation is
often optional in terms of the language spec., but that is besides the
point.

Python has not, AFAIK, deliberately opted out of that 'anything
whenever it's the right thing' use of blocks. It has tended to only
use a restricted type of block, but not out of principle - only as a
side-effect of something else. Other kinds of blocks may still be 'the
right thing'.


Besides, I'm not confident that the distinction you have drawn is
valid.

Any statement in 'if', 'while' and 'for' indented blocks is 'normal'.
What is modified is NOT how the code is run, but merely whether, when,
or how many times the block as a whole is run. Once the code in the
block is entered, it progresses normally just as if it was not in an
indented block.

Compare that with the code within a class or function definition.
There is more 'strange' going on than just control over when the code
is executed. Assignments and definitions operate differently, so that
the items assigned or defined end up in a different namespace
dictionary.

If it is valid to modify assignments and definitions such that the
targets of assignments and declarations are different, then why isn't
it valid to change other aspects of the way that assignments and
declarations are completed? IMO, there is no fundamental difference
between decorating and redirecting in this context. All it implies,
after all, is that the current dictionary gets wrapped with something
that overrides __setattr__ (to something that applies the decorators
before calling the wrapped dictionarys __setattr__).

Basically, even if there were any principle behind restricting what an
indented block can do beyond asking 'what is the right thing' (which
AFAIK there isn't), class and def blocks already do, in part,
essentially the same thing that a decorate block would do (tweak the
way that assignments and definitions operate by changing the
dictionary that they target).


>may still be an option, but it doesn't answer your request for a
>*single* preamble.  I agree that creating a lambda *just* to bundle
>the decorators is ugly, but if you really have a large number of
>decorators that always go together ... maybe there is a good name
>for the collection.

There are frequently many functions in a class that follow a similar
pattern simply because they do similar jobs. Take, for instance, the
following in the Python string class...

  isalnum, isalpha, isdigit, islower,
  isspace, istitle, isupper

Isn't it logical that if one function in such a group needed
decorating, all of them would? Of course it is!

Does that mean that there is some link between the decorations, or
that there is a sensible name for the whole set of decorations? Of
course not!

The pattern in the decorations is another example of a spandrel - the
reason for the pattern lies elsewhere (in the overall similarity
between the member functions) and has nothing much to do with the
meanings of the decorators.


-- 
Steve Horne

steve at ninereeds dot fsnet dot co dot uk