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