Call for signatories for J2

Arthur ajsiegel at optonline.com
Mon Aug 30 15:58:24 EDT 2004


"Peter Hansen" <peter at engcorp.com> wrote in message
news:VPSdnRsGq9ImH67cRVn-vg at powergate.ca...
> Arthur wrote:
> > There is some other syntactical aim here that I wouldn't call "sugar".
Once
> > again, in the context of "decorators", we might need a new word to
express
> > what the intention is here.
> >
> > If a core argument in favor is to shortcut programmer input, I think it
> > should be expressed as an unadorned shortcut.  And think @ expresses the
> > intent, in this respect more baldly and clearly.
>
> It looked a whole awful lot to me like the driving force behind
> the decorator syntax was not to shortcut programmer input, but
> to move the decorator up to a more prominent position than it
> occupied with the existing syntax (i.e. after the function,
> possibly even after lots of other functions, and thus somewhat
> hidden from the reader).
>
> Shortcutting programmer input has, as far as I can tell, never
> been a goal of Python syntax except, perhaps, the += form when
> applied merely to primitives...
>

I guess it is a matter of which parts of the discussion one heard louder.
Certainly there was a lot of comments from some of the folks much interested
in seeing this syntax about the PITA of typing:

some_long_name=foo(some_long_name)

This issue is undeniably real.

The readibility issue is purely theoretical.  I am not aware of anyone
reporting real isses in real practice.

So I guess I took the shortcut issue as the more real of the issues.

@ sort of spells macro - in lay terms, at least.  And in my mind that is
closer to what we are looking at.

If we are going for aesthetics, and readibility - we are on the wrong course
in any casew, IMO.

Art






More information about the Python-list mailing list