Extending Python Syntax with @

[David MacQuigg]

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