Extending Python Syntax with @

On Thu, 11 Mar 2004 12:55:20 -0000, claird at lairds.com (Cameron Laird)
wrote:

>In article <2f9050pq22u53o7aqo9i8ebqj11vo9kilg at 4ax.com>,>David MacQuigg  <dmq at gain.com> wrote:>			.>			.>			.>>going to help me write some code, I won't have time to study it.  My>>understanding of lambda functions is simply that they are a way to>>squeeze functions into a tight space:>>>>list_of_funcs = [(lambda x: 2**x), (lambda x: 3**x), (lambda x: 4**x)]>>>>If you are not concerned about space, simply use normal defs:>>>>def f2(x): return 2**x>>def f3(x): return 3**x>>def f4(x): return 4**x>>list_of_funcs = [f2, f3, f4]>>>>Is there any other reason in Python to use lambdas?>			.>			.>			.>In fact, *that*'s not a reason.  Part of tribal lore--a true,>documented part, by the way--is that Big Cheese Guido depre->cates lambdas.  He says they're a mistake, and people shouldn't

Wow!!  And I thought it was just me.  Could you point me to a PEP or
other discussion?  I would sure like to know the history of this.
Could it be that in adding "lambda calculus" to Python, Guido was
snowed by the language theorists? <half wink>

I think it is really cool that a language can actually have a mistake
like this corrected.  In the commercial world I'm used to, such a
feature would become part of the core religion, and any questioning
would eventually be met with "There are just some things you can't
understand.  Get back to work!"

>be using 'em.  Whenever you feel like a lambda, define a named>function; it forces the developer to come up with a name for>the operation, and that's likely to make the code more read->able (I'm slightly abbreviating the argument here).>>Space, in the sense you're using it above, should NOT concern>Pythoneers.  Correctness and clarity of express should.

Agree 110%

>It pains my sensitivities every time you claim lambdas are>just a way of making functions "small".  Again, I understand>how natural that is from your background.  Around this >mathematician, 'twould be less distracting to run your finger->nails down a chalkboard.

Sorry for the pain, and many thanks for the enlightenment.

>I think this ties back to your broader original propositions:>the Python aesthetic assesses little merit for the brevity of>@-anything, and much for the presumed evocativeness of "yield".>An abundance of *good* keywords is a good thing.  That's>definitely not the attitude of all languages.

I agree that brevity in itself has little merit.  This whole
side-discussion on lambdas was on the presumption that brevity was the
intent.  I now think deprecation of this wart is the better
alternative.

The choice between adding a keyword and modifying an existing
statement with a standard 'modify' symbol may now be largely a matter
of personal preference.  ( 'yield' vs @return, 'self.x' vs @x ).
Still, there is a small syntactic burden added with each keyword.  We
just have to be careful that the benefit (evoking an instant meaning
to the majority of users) is actually realized.  

A new keyword 'printraw', would certainly do that.  It just doesn't
feel right to me, however.  So if we can't have
print @(separator = None) x,y,z
then I would opt for deprecating 'print' and going with the function
syntax proposed by Paul Prescod:
show(x,y,z, separator = None)

-- Dave