Extending Python Syntax with @

[Kyler Laird]

Re: Extending Python Syntax with @

claird@lairds.c om (Cameron Laird) writes:
[color=blue]
>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
>be using 'em.[/color]

Interesting! I had assumed lambdas to be a necessity. I rarely
used them until I learned Scheme, but I didn't realize there was
a clean alternative.
[color=blue]
>Whenever you feel like a lambda, define a named
>function;[/color]

How do you cleanly do that?
foo = range(-10, 10)
my_op = lambda x: float(x) / max(map(abs, foo))
bar = map(my_op, foo)

--kyler

[Nick Vargish]

Re: Extending Python Syntax with @

David MacQuigg <dmq@gain.com > writes:
[color=blue]
> Sorry if my intentions weren't clear in my original post.[/color]

If your intention wasn't humour, then yes, it was not clear. I
seriously thought you were joking.

Nick

--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y )-1),' Ojdl!Wbshjti!=o bwAcboefstobudi/psh?')

[John Roth]

Re: Extending Python Syntax with @


"Cameron Laird" <claird@lairds. com> wrote in message
news:1050odofl6 44aac@corp.supe rnews.com...[color=blue]
> In article <2f9050pq22u53o 7aqo9i8ebqj11vo 9kilg@4ax.com>,
> David MacQuigg <dmq@gain.com > wrote:
> .
> .
> .[color=green]
> >going to help me write some code, I won't have time to study it. My
> >understandin g of lambda functions is simply that they are a way to
> >squeeze functions into a tight space:
> >
> >list_of_func s = [(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_func s = [f2, f3, f4]
> >
> >Is there any other reason in Python to use lambdas?[/color]
> .
> .
> .
> 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
> 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).[/color]

I tend to agree, but for slightly different reasons. Lambdas
are a means of in-lining a function definition. However, they
are so restricted that we constantly get suggestions for
"improving" them by adding more syntax.

Given the restrictions, I see the natural growth path as leading
to a callable instance or a bound method, not a module level
function. Module level functions are a distraction; usually you
want to interface with an object, and module level functions make
that very difficult.

The other reason to avoid lambdas is the DRY principle:
Don't Repeat Yourself. Most uses of lambdas I've seen
lead to duplication in anything larger than a toy program.

What I'd really like is for all of the instructional material
with lambdas to just magically vanish and be replaced by
instructional material that does whatever it is in proper
object oriented fashion, using bound methods for callbacks.
Relegate lambda to a sidebar.

John Roth

[color=blue]
> --
>
> Cameron Laird <claird@phaseit .net>
> Business: http://www.Phaseit.net[/color]

[David MacQuigg]

Re: Extending Python Syntax with @

On Thu, 11 Mar 2004 14:09:47 GMT, Kyler Laird <Kyler@news.Lai rds.org>
wrote:
[color=blue]
>claird@lairds. com (Cameron Laird) writes:[color=green]
>> Whenever you feel like a lambda, define a named
>> function;[/color]
>
>How do you cleanly do that?
> foo = range(-10, 10)
> my_op = lambda x: float(x) / max(map(abs, foo))
> bar = map(my_op, foo)
>
>--kyler[/color]

foo = range(-10, 10)
# my_op = lambda x: float(x) / max(map(abs, foo))
def my_op(x): return float(x) / max(map(abs, foo))
bar = map(my_op, foo)

-- Dave

[Peter Hickman]

Re: Extending Python Syntax with @

David MacQuigg wrote:[color=blue]
> If you believe as I do that Python is not yet the ultimate language,
> and some syntactical changes are still to come, then it seems like
> using a very distinct symbol like @ may have some merits.[/color]

If what motivates you is the 'ultimate language' and think you can get
closer to it by adding special characters then you are going to be very
disappointed. The history of computing is littered with 'ultimate
languages' that have had much more thought put into them than adding
special characters to an existing language (C++ comes to mind) and they
all have in common the fact that they failed.

To be fair C++ was never touted as an 'ultimate language' but you get
the picture.

If you feel python has a significant flaw then say what it is and how
you believe it would best be addressed. Using @ as a special character
is just adding sugar to the syntax.

Maybe what we need is a language that has only a grammer and the syntax
/ vocabulary comes from the objects. Or is that AppleScript?

[Richie Hindle]

Re: Extending Python Syntax with @


[Cameron][color=blue]
> Whenever you feel like a lambda, define a named function;[/color]

[Kyler][color=blue]
> How do you cleanly do that?
> foo = range(-10, 10)
> my_op = lambda x: float(x) / max(map(abs, foo))
> bar = map(my_op, foo)[/color]

foo = range(-10, 10)
def my_op(x):
return float(x) / max(map(abs, foo))
bar = map(my_op, foo)

....did I misunderstand?

--
Richie Hindle
richie@entrian. com

[Cameron Laird]

Re: Extending Python Syntax with @

In article <40507cd4$0$158 45$afc38c87@new s.easynet.co.uk >,
Peter Hickman <peter@semantic o.com> wrote:

[Cameron Laird]

Re: Extending Python Syntax with @

In article <1050uf4afdkrje 5@news.supernew s.com>,
John Roth <newsgroups@jhr othjr.com> wrote:

[David MacQuigg]

Re: Extending Python Syntax with @

On Thu, 11 Mar 2004 12:55:20 -0000, claird@lairds.c om (Cameron Laird)
wrote:
[color=blue]
>In article <2f9050pq22u53o 7aqo9i8ebqj11vo 9kilg@4ax.com>,
>David MacQuigg <dmq@gain.com > wrote:
> .
> .
> .[color=green]
>>going to help me write some code, I won't have time to study it. My
>>understandi ng of lambda functions is simply that they are a way to
>>squeeze functions into a tight space:
>>
>>list_of_fun cs = [(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_fun cs = [f2, f3, f4]
>>
>>Is there any other reason in Python to use lambdas?[/color]
> .
> .
> .
>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[/color]

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!"
[color=blue]
>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.[/color]

Agree 110%
[color=blue]
>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
>mathematicia n, 'twould be less distracting to run your finger-
>nails down a chalkboard.[/color]

Sorry for the pain, and many thanks for the enlightenment.
[color=blue]
>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.[/color]

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

[John Roth]

Re: Extending Python Syntax with @


"David MacQuigg" <dmq@gain.com > wrote in message
news:mu2150t5pp k9f0n89uhkijtce 2htsga2dg@4ax.c om...[color=blue]
> On Thu, 11 Mar 2004 12:55:20 -0000, claird@lairds.c om (Cameron Laird)
> wrote:
>[color=green]
> >In article <2f9050pq22u53o 7aqo9i8ebqj11vo 9kilg@4ax.com>,
> >David MacQuigg <dmq@gain.com > wrote:
> > .
> > .
> > .[color=darkred]
> >>going to help me write some code, I won't have time to study it. My
> >>understandi ng of lambda functions is simply that they are a way to
> >>squeeze functions into a tight space:
> >>
> >>list_of_fun cs = [(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_fun cs = [f2, f3, f4]
> >>
> >>Is there any other reason in Python to use lambdas?[/color]
> > .
> > .
> > .
> >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[/color]
>
> 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>[/color]

There's a presentation on the Python site - go to Doc, then to
Guido's Essay's, then to Presentations. It's called Python Regrets.
Google has an HTML version if you use "Python Regrets Guido"
as the keywords.

The lambda keyword really has almost nothing to do with the
lambda calculus: it's about a number of functional extensions
that are all being phased out over a period of time.

[color=blue]
> 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!"[/color]

There are a few too many of these in Python as well. It's going
to be a long time for the language to evolve, especially since
there seems to be a religious cult that is holding on to release
1.5.2 like it will insure their salvation.

John Roth
[color=blue]
>[/color]

[David MacQuigg]

Re: Extending Python Syntax with @

On Thu, 11 Mar 2004 13:15:39 +0100, Peter Maas
<fpetermaas@net scape.net> wrote:
[color=blue]
>David MacQuigg schrieb:[color=green]
>> Seems like we need a simple way to extend Python syntax that doesn't
>> break existing syntax or clash with any other syntax in Python,[/color]
>[...][color=green]
>> @x,y:x*x+y*y -- anonymous function[/color]
>
>Advantage of your proposal:
>
>- easy to extend the language without breaking existing code.
>
>Disadvantage s of your proposal:
>
>- The advantage is also a disadvantage: a lowered barrier for
> new semantics could bloat the language definition. Python's
> strength is that it has *few* concepts that are usable in *many*
> places. This could be compromised by your proposal.[/color]

This is actually a separate issue. Adding a few @ mods to selected
statements does not mean that users can add their own.
[color=blue]
>- Python is a readable language. lambda says "function literal",
> yield says "generator" , @ just says "different" . Python would
> be less readable if this notation would be adopted.[/color]

Readability, in this case, is in the eye of the beholder. 'lambda' to
me says 'wavelength', which I know has nothing to do with programming.
I suspect many users are like me, not enough computer science
background to know that lambda means 'function literal'.

'yield' is a little closer to the intent, but again, to most new users
it probably means something more like 'give way' or 'acquiesce', the
opposite of 'resist'. If you had never seen 'yield' used as it is now
in Python, and your first encounter with generator functions was when
you saw @return, would you not think "Ah yes, a modified return.", and
would that not be closer to reality than whatever you might associate
with the word 'yield'?

@ would never be used alone. Like the '\' symbol used as an escape,
its meaning beyond 'different' is seen by its context.

Again, these examples are to illustrate a discussion on syntax, not to
urge changing what has already been done. ( Althugh I just learned
from another part of this thread that 'lambda' *is* going to be
deprecated !! )

I almost wish Python had adopted the Unix philosphy of using short,
meaningless words for primitives. That would have avoided the problem
we are having now with 'print'. Words like 'cat' and 'grep' acquire
their own meaning, not dependent on previous meanings in English.

-- Dave

[Peter Hansen]

Re: Extending Python Syntax with @

David MacQuigg wrote:
[color=blue]
> 'yield' is a little closer to the intent, but again, to most new users
> it probably means something more like 'give way' or 'acquiesce', the
> opposite of 'resist'. If you had never seen 'yield' used as it is now
> in Python, and your first encounter with generator functions was when
> you saw @return, would you not think "Ah yes, a modified return.", and
> would that not be closer to reality than whatever you might associate
> with the word 'yield'?[/color]

No! The "give way" meaning is _much_ closer to what is going on than
"modified return", in my way of looking at it. Return winds up the call
stack and just happens to include a result value. Yield temporarily
"gives way" but leaves the stack frame in place, available for
resumption at a later time. You could say that the result value is
incidental, in the return case, while the permanent transfer of context
is the key thing. Just the opposite in the case of yield, and therefore
much different from a "modified return".

This is all semantics, probably, but I don't believe you can make a
strong case that yield is an ill-chosen name.

-Peter

[David MacQuigg]

Re: Extending Python Syntax with @

On Thu, 11 Mar 2004 11:17:08 -0500, "John Roth"
<newsgroups@jhr othjr.com> wrote:
[color=blue]
>"David MacQuigg" <dmq@gain.com > wrote in message
>news:mu2150t5p pk9f0n89uhkijtc e2htsga2dg@4ax. com...[/color]
[color=blue][color=green]
>> 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>[/color]
>
>There's a presentation on the Python site - go to Doc, then to
>Guido's Essay's, then to Presentations. It's called Python Regrets.
>Google has an HTML version if you use "Python Regrets Guido"
>as the keywords.[/color]

http://python.org/doc/essays/ppt/regrets/6

Interesting that Guido says lambda is confusing.

Interesting also that he is proposing two functions in place of
print(x,y,z):
write(x,y,z)
writeln(x,y,z)
This sounds very similar to Paul Prescod's proposal a few days ago on
this newsgroup, except that Paul is proposing to do it all with one
show() function. I like the one function.

Other surprises: Deprecating reload()

Thanks for the link.

-- Dave

[David MacQuigg]

Re: Extending Python Syntax with @

On Thu, 11 Mar 2004 12:01:57 -0500, Peter Hansen <peter@engcorp. com>
wrote:
[color=blue]
>David MacQuigg wrote:
>[color=green]
>> 'yield' is a little closer to the intent, but again, to most new users
>> it probably means something more like 'give way' or 'acquiesce', the
>> opposite of 'resist'. If you had never seen 'yield' used as it is now
>> in Python, and your first encounter with generator functions was when
>> you saw @return, would you not think "Ah yes, a modified return.", and
>> would that not be closer to reality than whatever you might associate
>> with the word 'yield'?[/color]
>
>No! The "give way" meaning is _much_ closer to what is going on than
>"modified return", in my way of looking at it. Return winds up the call
>stack and just happens to include a result value. Yield temporarily
>"gives way" but leaves the stack frame in place, available for
>resumption at a later time. You could say that the result value is
>incidental, in the return case, while the permanent transfer of context
>is the key thing. Just the opposite in the case of yield, and therefore
>much different from a "modified return".[/color]

A normal return terminates the function and returns a result. A
modified return (yield) suspends the function and returns a result.
[color=blue]
>This is all semantics, probably, but I don't believe you can make a
>strong case that yield is an ill-chosen name.[/color]

It's not ill chosen, just arbitrary. I would be just as happy with
'rtn' or 'tsr' or any fanciful word that doesn't convey a _wrong_
meaning.

We seem to have lost the top of this sub-thread, which is what I was
responding to:
[color=blue]
>- Python is a readable language. lambda says "function literal",
> yield says "generator" ,[/color]

All I'm saying is that these names don't convey the stated meanings to
most new users. I could be wrong, as I haven't done a survey.

-- Dave

[John Roth]

Re: Extending Python Syntax with @


"David MacQuigg" <dmq@gain.com > wrote in message
news:u39150l221 8blgkduajrrlsju 7760sclpd@4ax.c om...[color=blue]
> On Thu, 11 Mar 2004 11:17:08 -0500, "John Roth"
> <newsgroups@jhr othjr.com> wrote:
>[color=green]
> >"David MacQuigg" <dmq@gain.com > wrote in message
> >news:mu2150t5p pk9f0n89uhkijtc e2htsga2dg@4ax. com...[/color]
>[color=green][color=darkred]
> >> 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>[/color]
> >
> >There's a presentation on the Python site - go to Doc, then to
> >Guido's Essay's, then to Presentations. It's called Python Regrets.
> >Google has an HTML version if you use "Python Regrets Guido"
> >as the keywords.[/color]
>
> http://python.org/doc/essays/ppt/regrets/6
> Interesting that Guido says lambda is confusing.
>
> Interesting also that he is proposing two functions in place of
> print(x,y,z):
> write(x,y,z)
> writeln(x,y,z)
> This sounds very similar to Paul Prescod's proposal a few days ago on
> this newsgroup, except that Paul is proposing to do it all with one
> show() function. I like the one function.[/color]

There's also a basic difference. Write takes a string (or
strings with the proposal). Print took anything and called
str() or repr() to convert.

The difference between write and writeln is that the latter
puts in the return. Since it's on Guido's list, and since I
don't think it will cause compatibility problems, I suspect
that a patch to do it wouldn't be rejected out of hand. I'd
suggest making writeln (which is a new method) default
to inserting a single space, and leave write to default to
not inserting anything between the strings. (And remember
to do the doc update at the same time - the core developers
really like that.)
[color=blue]
> Other surprises: Deprecating reload()[/color]

Reload doesn't work the way most people think
it does: if you've got any references to the old module,
they stay around. They aren't replaced.

It was a good idea, but the implementation simply
doesn't do what the idea promises.
[color=blue]
>
> Thanks for the link.[/color]

You're welcome.
[color=blue]
>
> -- Dave[/color]

John Roth[color=blue]
>[/color]