[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