[Python-Dev] Re: Decorators: vertical bar syntax
Paul Moore
pf_moore at yahoo.co.uk
Sun Aug 8 18:35:16 CEST 2004
Fernando Perez <fperez528 at yahoo.com> writes:
>>> def foo(arg1, arg2):
>
> Ok, a new function foo() goes in, it takes 2 args, arg1 and arg2.
> Make mental bucket labeled 'foo'. Anything that comes now, until we
> de-indent, goes into box 'foo'. No need to keep random bits of
> information up in the air until I know where they're supposed to go.
Add a double-take here, because this is a method whose first argument
isn't "self". We can't be sure it's not right yet, because of the
staticmethod decorator, but store that for later thinking about...
>
>>> |classmethod
>
> Store 'classmethod' in bucket 'foo'.
Oops. If we recall, foo doesn't have a "self" first argument, but
neither does it have "cls". probably an error somewhere here, but we
have to wait until the decorators are over to be sure.
>
>>> |accepts(int, int)
>
> Store 'accepts(int, int)' in bucket 'foo'.
>
>>> |returns(float)
>
> Store 'returns(float)' in bucket 'foo'.
>
> Done. All information is stored in mental bucket 'foo', where it
> belongs.
But we have a couple of inconsistencies to backtrack and resolve. (And
the accepts/returns stuff is also inconsistent, but I'll stop picking
holes in what is clearly just an example...)
I'm not saying that the same issues mightn't exist with the
decorator-before-def form, but I don't think the mental model for the
decorator-after-def form is quite as clean as you'd like either...
It's still subjective :-)
Paul
--
The major difference between a thing that might go wrong and a thing
that cannot possibly go wrong is that when a thing that cannot
possibly go wrong goes wrong it usually turns out to be impossible to
get at or repair. -- Douglas Adams
More information about the Python-Dev
mailing list