Re: [Python-ideas] A simple proposal concerning lambda

[Stephan Houben]

Op do 23 aug. 2018 09:06 schreef Jacco van Dorp :

> I think it would have been better to use def from the start instead of
> lambda. The only thing JS does right is using the same "function" keyword
> for both of these.
>


Seriously?

Consider how the following code

function f() { return 42; }

may or may not bind the function to f, depending on if it appears in
expression or statement context. Just Google and find all the newbies who
get confused about this.

And the proposed def syntax is almost as terrible:

def greet: print("hello'')

This would then be legal, and leave the newbie confused why greet remains
undefined.

Please don't repurpose def.
Repurposing for and if inside comprehensions is already confusing to
newbies.

Stephan

>
> However, changing it now doesn't seem that important to me.
>
> (And I've used lambda's as default argument - I was moving data from one
> database to another, and wanted a generic method to switch out column names
> that defaulted to the same header. So it became a lambda x:x function by
> default, but you can provide any function that takes and returns a string
> and change the column names. This was last week.)
>
> And lets be real - adding a new keyword is something to be done extremely
> sparingly. lambda could have been avoided by re-using def. And no, it being
> the same keyword is an advantage, as they do the exact same - they create a
> function. It's the same reason as we use if condition:
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Jacco van Dorp]

I think it would have been better to use def from the start instead of
lambda. The only thing JS does right is using the same "function" keyword
for both of these.

However, changing it now doesn't seem that important to me.

(And I've used lambda's as default argument - I was moving data from one
database to another, and wanted a generic method to switch out column names
that defaulted to the same header. So it became a lambda x:x function by
default, but you can provide any function that takes and returns a string
and change the column names. This was last week.)

And lets be real - adding a new keyword is something to be done extremely
sparingly. lambda could have been avoided by re-using def. And no, it being
the same keyword is an advantage, as they do the exact same - they create a
function. It's the same reason as we use if condition:
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Rhodri James]

On 22/08/18 17:59, Chris Barker via Python-ideas wrote:

On Wed, Aug 22, 2018 at 9:51 AM, Stephan Houben
wrote:


Let me stand up and say that I personally like lambda. It's the standard
terminology and not easily confused.


I agree.

And secondly, even if I didn't like it, changing the name of something
because it's a slightly less confusing name to newbies is a really low
priority!


Jonathan isn't proposing to change the name, just to add a synonym.  The 
obvious quote from the Zen at this point is:


"There should be one-- and preferably only one --obvious way to do it."

--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Steven D'Aprano]

On Tue, Aug 21, 2018 at 09:57:51PM -0500, Abe Dillon wrote:
> [Chris Angelico]
> 
> > If you have a use-case for a lambda function that takes a callback and
> > has a default value for that callback, please submit it to The Daily
> > WTF. In Steve's example, the main function was created with a
> > statement.
> 
> 
> Fair enough, but I still think D'Aprano may have engineered his example to
> be particularly unreadable.

I picked the example to showcase an example of where this suggested new 
syntax looks bad. Part of debating proposals is to look at pros and 
cons, not just to look at the best cases.

But it wasn't an engineered example in the sense of "invented just for 
this purpose". Of course I used metasyntactic variables rather than real 
code, but I assure you I have real code that uses lambda in function 
parameter lists. Nor am I the only one.

For example, I have a private module (fortunately now retired) that 
backports itertools to older versions of Python, and it includes a 
version of groupby that looks like this:

class groupby(object):
def __init__(self, iterable, key=lambda obj: obj):
...


I, er, "borrowed" a Prime number sieve class from somewhere (and forget 
where, so I can't give credit where credit is due) and it starts like 
this:

class Primes(object):
def __init__(self, n=None, extend=False, exf=lambda x:x + x//2):


The std lib contains a test that this correctly raises SyntaxError:

def f(*, x=lambda __debug__:0): pass

(the problem here is that __debug__ cannot be used as a parameter name).

So its not just me who uses lambda as a default argument.



> Why would you use 'arg' for both the argument to the method and the
> callback! That's at least a little WTF.

Heh, I didn't even notice that. It certainly wasn't intentional. Sorry.




-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Steven D'Aprano]

On Wed, Aug 22, 2018 at 04:58:17PM +0100, Jonathan Fine wrote:
> I wrote:
> 
> > Here is my simple proposal. Enhance Python to allow
> >
> > >>> hn = def a, b=2, c=3: a ** b / c
> 
> I'd like to add a clarification. Here are two proposals.
> 
> ONE.  Wherever you could have used 'lambda', you now have a choice.
> You can still use 'lambda', or you can use 'def' instead. The
> semantics are unchanged.
> 
> TWO.  Wherever you could have used 'lambda', you must now use 'def'
> instead. The semantics are unchanged.
> 
> I'm proposing ONE, not TWO. All existing Python code will continue to
> run exactly as before. No Python code will have to be changed. And no
> new programming capabilities would be added.
> 
> So why do it? In a nutshell, to remove an obstacle. 

And add a new obstacle:

"What's the difference between function expressions created with def and 
function expressions created with lambda?"

"Nothing."

"So why do I have to learn TWO sets of syntax for exactly the same 
thing?"

"Because its easier than learning one!"



> To make DEFerred expressions easier to understand.

They're not "deferred expressions", they're functions.

It is true that function bodies contain deferred expressions (or 
statements), but the whole is not the part.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Chris Barker via Python-ideas]

On Wed, Aug 22, 2018 at 9:51 AM, Stephan Houben 
wrote:

> Let me stand up and say that I personally like lambda. It's the standard
> terminology and not easily confused.
>

I agree.

And secondly, even if I didn't like it, changing the name of something
because it's a slightly less confusing name to newbies is a really low
priority!

If you look back at previous discussion, the real push was to exp[and
lambda's capabilities -- maybe allow more than one expression, or ??? But
that would make it MORE confusing to newbies, not less.

I actually think it makes a strikes a pretty good balance -- to use the
idiomatic phrase :-)

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Stephan Houben]

Let me stand up and say that I personally like lambda. It's the standard
terminology and not easily confused.

I doubt that "many Python users" have a problem with it. Evidence?

I dislike the def proposal strongly.
It is too similar to a normal def.
At least get a new keyword then

Some other languages:

lambda: scheme, lisp
\ : Haskell
fn : Standard ml
function : JavaScript
[] : C++

Stephan



Op wo 22 aug. 2018 18:16 schreef Mike Miller :

> I've often thought the same about "lambda."
>
> Although I've long since gotten used to the word, "def" without a function
> name
> seemed like a better choice, especially for beginners.
>
> +0.25 for proposal ONE
>
> However, parentheses should be allowed and lambda put on a long
> deprecation
> schedule.
>
> -Mike
>
>
> On 2018-08-22 08:58, Jonathan Fine wrote:
> >
> > ONE.  Wherever you could have used 'lambda', you now have a choice.
> > You can still use 'lambda', or you can use 'def' instead. The
> > semantics are unchanged.
> >
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Brice Parent]

Le 22/08/2018 à 04:12, MRAB a écrit :

On 2018-08-22 02:38, Elazar wrote:
I don't think this change makes sense, but if it's done, there should 
be another change, with actual implications:
There is no way to express the types of the parameters in a lambda - 
`lambda x: int : x` is obviously a syntax error. Replacing the colon 
with a different symbol, such as "=>" will make this possible:


     def x => x
     def x: int => x
     def x: int -> int => x

It will also give one less meaning to the colon.


The examples I showed had parens, so your examples could be:

    def (x): x
    def (x: int): x
    def (x: int) -> int: x
With or without allowing `def` to be an equivalent of `lambda`, I think 
this is a great idea.

To me, someone who understands the following 2 lines:

lambda x, y: x * y
def a(x: float, y: int) -> float: ...

would probably understand the following:

lambda(x: float, y: int) -> float: x * y

(more type hints, I like it!)

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Mike Miller]

I've often thought the same about "lambda."

Although I've long since gotten used to the word, "def" without a function name 
seemed like a better choice, especially for beginners.


+0.25 for proposal ONE

However, parentheses should be allowed and lambda put on a long deprecation 
schedule.


-Mike


On 2018-08-22 08:58, Jonathan Fine wrote:


ONE.  Wherever you could have used 'lambda', you now have a choice.
You can still use 'lambda', or you can use 'def' instead. The
semantics are unchanged.



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Jonathan Fine]

I wrote:

> Here is my simple proposal. Enhance Python to allow
>
> >>> hn = def a, b=2, c=3: a ** b / c

I'd like to add a clarification. Here are two proposals.

ONE.  Wherever you could have used 'lambda', you now have a choice.
You can still use 'lambda', or you can use 'def' instead. The
semantics are unchanged.

TWO.  Wherever you could have used 'lambda', you must now use 'def'
instead. The semantics are unchanged.

I'm proposing ONE, not TWO. All existing Python code will continue to
run exactly as before. No Python code will have to be changed. And no
new programming capabilities would be added.

So why do it? In a nutshell, to remove an obstacle. To make DEFerred
expressions easier to understand. Is it worth doing? That's a
cost-benefit analysis. I think the main benefit will be in the docs,
and in teaching people Python.

And does it fit in with the Zen of Python?

> There should be one-- and preferably only one --obvious way to do it.
> Although that way may not be obvious at first unless you're Dutch.

So is having both 'def' and 'lambda' unpythonic? Two ways to do the same thing!

With PEP 572 (see exceptional cases), the following are equivalent:
>>> a = 1
>>> (a := 1)

And we're allowed to use tabs or spaces for indentation (see PEP 666).

So *maybe* having both 'lambda' and 'def' is sufficiently Pythonic.

-- 
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Abe Dillon]

[Chris Angelico]

> Though... it's insignificant when the function header precedes the
> expression/body. With the proposal to move the header to the end, that
> might become problematic, which makes it yet another cost to the
> proposal.


I don't think it would be a problem because, like ternary and other
circuiting operations, the expression isn't evaluated until certain
criteria are met.
The arrangement shouldn't matter.

...I think.

On Tue, Aug 21, 2018 at 10:10 PM Chris Angelico  wrote:

> On Wed, Aug 22, 2018 at 12:57 PM, Abe Dillon  wrote:
> > [Chris Angelico]
> >>
> >> If you have a use-case for a lambda function that takes a callback and
> >> has a default value for that callback, please submit it to The Daily
> >> WTF. In Steve's example, the main function was created with a
> >> statement.
> >
> >
> > Fair enough, but I still think D'Aprano may have engineered his example
> to
> > be particularly unreadable.
> > Why would you use 'arg' for both the argument to the method and the
> > callback! That's at least a little WTF.
>
> True, but hardly significant. The one inside lambda is local to it.
>
> Though... it's insignificant when the function header precedes the
> expression/body. With the proposal to move the header to the end, that
> might become problematic, which makes it yet another cost to the
> proposal.
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Chris Angelico]

On Wed, Aug 22, 2018 at 12:57 PM, Abe Dillon  wrote:
> [Chris Angelico]
>>
>> If you have a use-case for a lambda function that takes a callback and
>> has a default value for that callback, please submit it to The Daily
>> WTF. In Steve's example, the main function was created with a
>> statement.
>
>
> Fair enough, but I still think D'Aprano may have engineered his example to
> be particularly unreadable.
> Why would you use 'arg' for both the argument to the method and the
> callback! That's at least a little WTF.

True, but hardly significant. The one inside lambda is local to it.

Though... it's insignificant when the function header precedes the
expression/body. With the proposal to move the header to the end, that
might become problematic, which makes it yet another cost to the
proposal.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Abe Dillon]

[Chris Angelico]

> If you have a use-case for a lambda function that takes a callback and
> has a default value for that callback, please submit it to The Daily
> WTF. In Steve's example, the main function was created with a
> statement.


Fair enough, but I still think D'Aprano may have engineered his example to
be particularly unreadable.
Why would you use 'arg' for both the argument to the method and the
callback! That's at least a little WTF.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Chris Angelico]

On Wed, Aug 22, 2018 at 12:48 PM, Abe Dillon  wrote:
> [Steven D'Aprano]
>>
>> Replacing the keyword:
>> results = map(def a, b=2, c=3: a ** b / c, sequence)
>> widget.register(callback=def: spam.eggs())
>> Doesn't look so attractive now, I wager. Using "def" inside an
>> expression looks strange. And this looks outright disturbing:
>> def method(self, arg, callback=def arg: arg+1):
>> pass
>
>
> Eh... I think they look fine. Which is worse:
>
> def method(self, arg, callback=def arg: arg+1):
> pass
>
> or
>
> lambda arg, callback=lambda arg: arg+1: None
>
> because the second one makes me go cross-eyed...

If you have a use-case for a lambda function that takes a callback and
has a default value for that callback, please submit it to The Daily
WTF. In Steve's example, the main function was created with a
statement.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Abe Dillon]

[Steven D'Aprano]

> most importantly, "def" with "fun", which will have the
> advantage of making Python programming more fun!


I'm sold. Make the change and SHIP IT!
No need for committee approval.

[Steven D'Aprano]

> If we're going to break people's code by
> changing keywords, let's do it properly! *wink*


I'm not backing this proposal, but I am curious what the proposal could
break.

[Steven D'Aprano]

> - Two fewer keystrokes.


THREE!!!

[Steven D'Aprano]

> - but "def" is still jargon that needs to be learned.


It already has to be learned and it's already associated with function
declaration.

[Steven D'Aprano]

> I don't think this cosmetic change comes even close to the break-even
> point of costs versus benefits. Maybe if we were designing Python from
> scratch today, there would be a good argument to be made for using def
> in both the statement and expression form, but even that's not a sure
> thing. Changing it *now* is more costly with less benefit.


Yeah, that's pretty much my take on the matter.
That ship sailed way back when Py3k was finalized.

[Steven D'Aprano]

> To give an example of a problematic keyword where changing it is not
> just cosmetic, for many years, consider the "for...else" statement. It
> seems to be saying:
> run the for loop
> *or else* run this block
> but that's not what it actually means. But even if we had consensus that
> the "else" keyword should be changed (to what? "then" is my suggestion),
> the benefit is probably too small to disrupt the Python ecosystem by
> actually making that change.


for-finished?
for-done?
for-stopped?  # referencing StopIteration
for-anything_but_else?

[Steven D'Aprano]
>
> By the way, I'll also point out that the way you have demonstrated the
> use of anonymous functions is considered a (mild) abuse of syntax. Your
> example:
> # reverting back to lambda for the moment
> hn = lambda a, b=2, c=3: a ** b / c
> ought to be written as:
>def hn(a, b=2, c=3): return a ** b / c


Oh, come-on; D'Aprano! That was just to demonstrate properties of the
resulting object.
It's not meant to be production code.

[Steven D'Aprano]

> Replacing the keyword:
> results = map(def a, b=2, c=3: a ** b / c, sequence)
> widget.register(callback=def: spam.eggs())
> Doesn't look so attractive now, I wager. Using "def" inside an
> expression looks strange. And this looks outright disturbing:
> def method(self, arg, callback=def arg: arg+1):
> pass


Eh... I think they look fine. Which is worse:

def method(self, arg, callback=def arg: arg+1):
pass

or

lambda arg, callback=lambda arg: arg+1: None

because the second one makes me go cross-eyed...

On Tue, Aug 21, 2018 at 8:55 PM, Steven D'Aprano 
wrote:

> On Tue, Aug 21, 2018 at 10:27:20PM +0100, Jonathan Fine wrote:
>
> > Here is my simple proposal. Enhance Python to allow
> >
> > >>> hn = def a, b=2, c=3: a ** b / c
>
> Enhancements ought to allow us to write new code that we couldn't do
> before, or open up new kinds of algorithms that weren't easy or possible
> before.
>
> This is a mere cosmetic change, replacing a perfectly valid keyword with
> one which clashes with an existing keyword in what I consider to be an
> ugly way.
>
> While we're at it, perhaps we ought to replace:
>
> - "else" with "otherwise"
>   ("else" is a weird word, outside of programming we hardly ever use it
>   without a leading "or")
>
> - "import" with "load" (shorter)
>
> - "for" with "repeat with"
>   (I've always found it awkward that the word "for" sounds like an number)
>
> - "raise" with "throw"
>
> - and most importantly, "def" with "fun", which will have the
>   advantage of making Python programming more fun!
>
> Admittedly these run into backwards-compatibility issues, which your
> suggestion does not. But if we're going to break people's code by
> changing keywords, let's do it properly! *wink*
>
> Changing the public API of a language, its keywords, is not something to
> be done lightly. The consequences of such a change can include:
>
> - breaking backwards compatibility;
>
> - code churn (people have to "fix their code" even if it wasn't broken);
>
> - confusion ("what's the difference between def anonymous functions
>   and lambda anonymous functions?");
>
> - more to learn during the transition (sometimes code uses lambda,
>   sometimes def, so you need to know both)
>
> - more documentation explaining why the name is only sometimes needed;
>
> - more unit tests etc to ensure the feature works correctly, e.g. to
>   test for the syntax error when people use def unanonymously when
>   they should use it anonymously:
>
>   map(def func(a, b, c): a+b-c, zip(seq1, seq2, seq3))
>
>
> Those costs are real and should only be paid when the benefits outweigh
> the costs. In this specific case, there's also a very real cost:
>
> - you will *seriously annoy and frustrate* those of us who like lambda
>   and dislike the look of "def" inside expressions;
>
> - while only *sl

Re: [Python-ideas] A simple proposal concerning lambda

[MRAB]

On 2018-08-22 02:38, Elazar wrote:
I don't think this change makes sense, but if it's done, there should be 
another change, with actual implications:
There is no way to express the types of the parameters in a lambda - 
`lambda x: int : x` is obviously a syntax error. Replacing the colon 
with a different symbol, such as "=>" will make this possible:


     def x => x
     def x: int => x
     def x: int -> int => x

It will also give one less meaning to the colon.


The examples I showed had parens, so your examples could be:

def (x): x
def (x: int): x
def (x: int) -> int: x



On Tue, Aug 21, 2018 at 6:28 PM MRAB > wrote:


On 2018-08-22 01:25, Jonathan Fine wrote:
 > Hi Abe
 >
 > Summary: You've done good work here. I've skim read the 2006
 > discussion you found.
 >
 > You wrote:
 >
 >> I'm trying to dig up past threads about alternatives to lambda
because I
 >> would be astonished if "def" hadn't been considered and rejected
for some
 >> reason. What I've found so far is this unreassuring  post from
Guido back in
 >> 2006
 >
 >> [Python-Dev] Let's just *keep* lambda
 >>
https://mail.python.org/pipermail/python-dev/2006-February/060415.html
 >
 > This is an excellent piece of work. I'm most grateful. Here's
what Guido said:
 >
 >> After so many attempts to come up with an alternative for lambda,
 >> perhaps we should admit defeat. I've not had the time to follow the
 >> most recent rounds, but I propose that we keep lambda, so as to stop
 >> wasting everybody's talent and time on an impossible quest.
 >
 > I've quickly read through the posts that followed Guido's message,
 > picked out the ones that interest me. Here's a list.
 >
 >>
https://mail.python.org/pipermail/python-dev/2006-February/060487.html
 >>
https://mail.python.org/pipermail/python-dev/2006-February/060474.html
 >>
https://mail.python.org/pipermail/python-dev/2006-February/060471.html
 >>
https://mail.python.org/pipermail/python-dev/2006-February/060445.html
 >>
https://mail.python.org/pipermail/python-dev/2006-February/060435.html
 >>
https://mail.python.org/pipermail/python-dev/2006-February/060431.html
 >>
https://mail.python.org/pipermail/python-dev/2006-February/060470.html
 >
 > And one of the messages had a link to still live and excellent page
 >
 >> https://wiki.python.org/moin/AlternateLambdaSyntax
 >
 > This page lists over 100 suggestions, mostly variants. So far as
I can
 > see, my simple proposal isn't listed on that page. The page also says
 >
Hmm.

That lists:

      def (a, b, c): return f(a) + o(b) - o(c)

and:

      def (a, b, c) = f(a) + o(b) - o(c)

but not:

      def (a, b, c): f(a) + o(b) - o(c)

 >> **Definitely Desirable Features**
 > [snip]
 >> *More friendly to inexperienced users*
 > [snip]
 >> Compared to other Python keywords, 'lambda' is rather esoteric.
 >> In the challenge for "farthest outside day-to-day English usage",
 >> its closest competitor would probably be 'assert', as even 'def'
 >> and 'elif' are just abbreviations for 'define' and 'else if'. Use of
 >> simpler keywords may make deferred expressions appear less
 >> intimidating than they seem with the current unusual keyword.
 >
 > The word 'deferred' appears 7 times on the page. It also appears in
 > the python-dev messages.
 >
 > If someone with more time and less bias then myself were to summarise
 > this discussion from 2006, I'd be most grateful, and they'd have
 > material for a great blog post.
 >
 > Finally, many thanks to Abe for finding this gem, and countless
 > people's hard work in keeping it alive to be found. Backwards
 > compatibility is there for a reason.
 >

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Abe Dillon]

[Jonathan Fine]

> one of the messages had a link to still live and excellent page
> > https://wiki.python.org/moin/AlternateLambdaSyntax
> This page lists over 100 suggestions, mostly variants. So far as I can
> see, my simple proposal isn't listed on that page. The page also says


Awesome!

Unfortunately the links to conversations seem to all be broken!

Most of the links are from December 2004, so I pulled up the discussion for
that month

and searched "lambda"

I was able to find what I believe is reference [1]:
https://mail.python.org/pipermail/python-list/2004-December/264515.html

It looks like the post numbers got mangled...

Anyway, it looks like that page covers December 2004-June 2005, I found a
few nuggets of opposition:

https://mail.python.org/pipermail/python-list/2004-December/247348.html

https://mail.python.org/pipermail/python-list/2004-December/273038.html

I sort-of understand the opposition to multi-line anonymous functions, but
I think the Terry Reedy (in the second link)
is a bit too dismissive of the concept of anonymous functions.

I don't work with user-interfaces a lot, but when I do; I can see why UI
coders use anonymous functions so much.
Defining a function in a statement can be far less expressive and far more
noisy than in an expression.
It's like: I'll tell you my solution, but first let me shave this Yak here.

You're defining often one-off functions before describing what you're going
to use it for.
It's only after you actually pass them to an event-watcher that the context
of their logic is clear.
For instance:

>>> def handler(event):  # First, let me tell you about a function
...   # It's a 1-off with a throw-away name
... return result  # You'll see what I need it for later...
...
>>> ui_element.on_mouseover(handler)

vs.

>>> # lack of noisy preamble to your code
>>> ui_element.on_mouseover( with event)

The anonymous function is given meaning by virtue of the context in-which
it's defined.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Stephen J. Turnbull]

Abe Dillon writes:

 > What I've found so far is this unreassuring post from Guido back in
 > 2006
 > 

IIRC, early drafts of PEP 3000 (the PEP that was the planning document
for the Python 3 project) removed lambda altogether.  However there
was strong opposition, so we ended up keeping lambda.  Some of those
discussions morphed to ideas about "improving" lambda.  So you may find
discussions of lambda in threads titled "PEP 3000" or "Python 3000".


-- 
Associate Professor  Division of Policy and Planning Science
http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information
Email: turnb...@sk.tsukuba.ac.jp   University of Tsukuba
Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Steven D'Aprano]

On Tue, Aug 21, 2018 at 10:27:20PM +0100, Jonathan Fine wrote:

> Here is my simple proposal. Enhance Python to allow
> 
> >>> hn = def a, b=2, c=3: a ** b / c

Enhancements ought to allow us to write new code that we couldn't do 
before, or open up new kinds of algorithms that weren't easy or possible 
before.

This is a mere cosmetic change, replacing a perfectly valid keyword with 
one which clashes with an existing keyword in what I consider to be an 
ugly way.

While we're at it, perhaps we ought to replace:

- "else" with "otherwise"
  ("else" is a weird word, outside of programming we hardly ever use it 
  without a leading "or")

- "import" with "load" (shorter)

- "for" with "repeat with" 
  (I've always found it awkward that the word "for" sounds like an number)

- "raise" with "throw"

- and most importantly, "def" with "fun", which will have the 
  advantage of making Python programming more fun!

Admittedly these run into backwards-compatibility issues, which your 
suggestion does not. But if we're going to break people's code by 
changing keywords, let's do it properly! *wink*

Changing the public API of a language, its keywords, is not something to 
be done lightly. The consequences of such a change can include:

- breaking backwards compatibility;

- code churn (people have to "fix their code" even if it wasn't broken);

- confusion ("what's the difference between def anonymous functions 
  and lambda anonymous functions?");

- more to learn during the transition (sometimes code uses lambda, 
  sometimes def, so you need to know both)

- more documentation explaining why the name is only sometimes needed;

- more unit tests etc to ensure the feature works correctly, e.g. to 
  test for the syntax error when people use def unanonymously when
  they should use it anonymously:

  map(def func(a, b, c): a+b-c, zip(seq1, seq2, seq3))


Those costs are real and should only be paid when the benefits outweigh 
the costs. In this specific case, there's also a very real cost:

- you will *seriously annoy and frustrate* those of us who like lambda 
  and dislike the look of "def" inside expressions;

- while only *slightly pleasing* those who have already learned lambda
  but don't like it. They've already learned the existing word, now they 
  have to unlearn it.

And the corresponding benefit is tiny:

- The conceptual difficulties with lambda is not the word but the
  concept of anonymous functions as first class values; that doesn't 
  change, so no benefit there.

- One less keyword in the language (after the transition period).

- Two fewer keystrokes.

- but "def" is still jargon that needs to be learned.

(Does it mean defeat, defame, defer, defend, or that thing bears do in 
the woods? To a non-English speaker, memorising "def" = "define" is no 
less obscure than memorising "lam" = "lambda" would be for English 
speakers.)

I don't think this cosmetic change comes even close to the break-even 
point of costs versus benefits. Maybe if we were designing Python from 
scratch today, there would be a good argument to be made for using def 
in both the statement and expression form, but even that's not a sure 
thing. Changing it *now* is more costly with less benefit.

To give an example of a problematic keyword where changing it is not 
just cosmetic, for many years, consider the "for...else" statement. It 
seems to be saying:

run the for loop

*or else* run this block

but that's not what it actually means. But even if we had consensus that 
the "else" keyword should be changed (to what? "then" is my suggestion), 
the benefit is probably too small to disrupt the Python ecosystem by 
actually making that change.

By the way, I'll also point out that the way you have demonstrated the 
use of anonymous functions is considered a (mild) abuse of syntax. Your 
example:

# reverting back to lambda for the moment
hn = lambda a, b=2, c=3: a ** b / c 

ought to be written as:

   def hn(a, b=2, c=3): return a ** b / c

which ensures that hn has a nice name for debugging. Lambdas ought to be 
limited to in-place uses, as part of a larger expression and not just an 
assignment, probably 99% of the time. Hence:

results = map(lambda a, b=2, c=3: a ** b / c, sequence)

widget.register(callback=lambda: spam.eggs())

are reasonable examples of how one might find lambdas in the wild. 
Replacing the keyword:

results = map(def a, b=2, c=3: a ** b / c, sequence)

widget.register(callback=def: spam.eggs())

Doesn't look so attractive now, I wager. Using "def" inside an 
expression looks strange. And this looks outright disturbing:

def method(self, arg, callback=def arg: arg+1):
pass



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Elazar]

I don't think this change makes sense, but if it's done, there should be
another change, with actual implications:
There is no way to express the types of the parameters in a lambda -
`lambda x: int : x` is obviously a syntax error. Replacing the colon with a
different symbol, such as "=>" will make this possible:

def x => x
def x: int => x
def x: int -> int => x

It will also give one less meaning to the colon.

Elazar

On Tue, Aug 21, 2018 at 6:28 PM MRAB  wrote:

> On 2018-08-22 01:25, Jonathan Fine wrote:
> > Hi Abe
> >
> > Summary: You've done good work here. I've skim read the 2006
> > discussion you found.
> >
> > You wrote:
> >
> >> I'm trying to dig up past threads about alternatives to lambda because I
> >> would be astonished if "def" hadn't been considered and rejected for
> some
> >> reason. What I've found so far is this unreassuring  post from Guido
> back in
> >> 2006
> >
> >> [Python-Dev] Let's just *keep* lambda
> >> https://mail.python.org/pipermail/python-dev/2006-February/060415.html
> >
> > This is an excellent piece of work. I'm most grateful. Here's what Guido
> said:
> >
> >> After so many attempts to come up with an alternative for lambda,
> >> perhaps we should admit defeat. I've not had the time to follow the
> >> most recent rounds, but I propose that we keep lambda, so as to stop
> >> wasting everybody's talent and time on an impossible quest.
> >
> > I've quickly read through the posts that followed Guido's message,
> > picked out the ones that interest me. Here's a list.
> >
> >> https://mail.python.org/pipermail/python-dev/2006-February/060487.html
> >> https://mail.python.org/pipermail/python-dev/2006-February/060474.html
> >> https://mail.python.org/pipermail/python-dev/2006-February/060471.html
> >> https://mail.python.org/pipermail/python-dev/2006-February/060445.html
> >> https://mail.python.org/pipermail/python-dev/2006-February/060435.html
> >> https://mail.python.org/pipermail/python-dev/2006-February/060431.html
> >> https://mail.python.org/pipermail/python-dev/2006-February/060470.html
> >
> > And one of the messages had a link to still live and excellent page
> >
> >> https://wiki.python.org/moin/AlternateLambdaSyntax
> >
> > This page lists over 100 suggestions, mostly variants. So far as I can
> > see, my simple proposal isn't listed on that page. The page also says
> >
> Hmm.
>
> That lists:
>
>  def (a, b, c): return f(a) + o(b) - o(c)
>
> and:
>
>  def (a, b, c) = f(a) + o(b) - o(c)
>
> but not:
>
>  def (a, b, c): f(a) + o(b) - o(c)
>
> >> **Definitely Desirable Features**
> > [snip]
> >> *More friendly to inexperienced users*
> > [snip]
> >> Compared to other Python keywords, 'lambda' is rather esoteric.
> >> In the challenge for "farthest outside day-to-day English usage",
> >> its closest competitor would probably be 'assert', as even 'def'
> >> and 'elif' are just abbreviations for 'define' and 'else if'. Use of
> >> simpler keywords may make deferred expressions appear less
> >> intimidating than they seem with the current unusual keyword.
> >
> > The word 'deferred' appears 7 times on the page. It also appears in
> > the python-dev messages.
> >
> > If someone with more time and less bias then myself were to summarise
> > this discussion from 2006, I'd be most grateful, and they'd have
> > material for a great blog post.
> >
> > Finally, many thanks to Abe for finding this gem, and countless
> > people's hard work in keeping it alive to be found. Backwards
> > compatibility is there for a reason.
> >
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[MRAB]

On 2018-08-22 01:25, Jonathan Fine wrote:

Hi Abe

Summary: You've done good work here. I've skim read the 2006
discussion you found.

You wrote:


I'm trying to dig up past threads about alternatives to lambda because I
would be astonished if "def" hadn't been considered and rejected for some
reason. What I've found so far is this unreassuring  post from Guido back in
2006



[Python-Dev] Let's just *keep* lambda
https://mail.python.org/pipermail/python-dev/2006-February/060415.html


This is an excellent piece of work. I'm most grateful. Here's what Guido said:


After so many attempts to come up with an alternative for lambda,
perhaps we should admit defeat. I've not had the time to follow the
most recent rounds, but I propose that we keep lambda, so as to stop
wasting everybody's talent and time on an impossible quest.


I've quickly read through the posts that followed Guido's message,
picked out the ones that interest me. Here's a list.


https://mail.python.org/pipermail/python-dev/2006-February/060487.html
https://mail.python.org/pipermail/python-dev/2006-February/060474.html
https://mail.python.org/pipermail/python-dev/2006-February/060471.html
https://mail.python.org/pipermail/python-dev/2006-February/060445.html
https://mail.python.org/pipermail/python-dev/2006-February/060435.html
https://mail.python.org/pipermail/python-dev/2006-February/060431.html
https://mail.python.org/pipermail/python-dev/2006-February/060470.html


And one of the messages had a link to still live and excellent page


https://wiki.python.org/moin/AlternateLambdaSyntax


This page lists over 100 suggestions, mostly variants. So far as I can
see, my simple proposal isn't listed on that page. The page also says


Hmm.

That lists:

def (a, b, c): return f(a) + o(b) - o(c)

and:

def (a, b, c) = f(a) + o(b) - o(c)

but not:

def (a, b, c): f(a) + o(b) - o(c)


**Definitely Desirable Features**

[snip]

*More friendly to inexperienced users*

[snip]

Compared to other Python keywords, 'lambda' is rather esoteric.
In the challenge for "farthest outside day-to-day English usage",
its closest competitor would probably be 'assert', as even 'def'
and 'elif' are just abbreviations for 'define' and 'else if'. Use of
simpler keywords may make deferred expressions appear less
intimidating than they seem with the current unusual keyword.


The word 'deferred' appears 7 times on the page. It also appears in
the python-dev messages.

If someone with more time and less bias then myself were to summarise
this discussion from 2006, I'd be most grateful, and they'd have
material for a great blog post.

Finally, many thanks to Abe for finding this gem, and countless
people's hard work in keeping it alive to be found. Backwards
compatibility is there for a reason.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Jonathan Fine]

Hi Abe

Summary: You've done good work here. I've skim read the 2006
discussion you found.

You wrote:

> I'm trying to dig up past threads about alternatives to lambda because I
> would be astonished if "def" hadn't been considered and rejected for some
> reason. What I've found so far is this unreassuring  post from Guido back in
> 2006

> [Python-Dev] Let's just *keep* lambda
> https://mail.python.org/pipermail/python-dev/2006-February/060415.html

This is an excellent piece of work. I'm most grateful. Here's what Guido said:

> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and time on an impossible quest.

I've quickly read through the posts that followed Guido's message,
picked out the ones that interest me. Here's a list.

> https://mail.python.org/pipermail/python-dev/2006-February/060487.html
> https://mail.python.org/pipermail/python-dev/2006-February/060474.html
> https://mail.python.org/pipermail/python-dev/2006-February/060471.html
> https://mail.python.org/pipermail/python-dev/2006-February/060445.html
> https://mail.python.org/pipermail/python-dev/2006-February/060435.html
> https://mail.python.org/pipermail/python-dev/2006-February/060431.html
> https://mail.python.org/pipermail/python-dev/2006-February/060470.html

And one of the messages had a link to still live and excellent page

> https://wiki.python.org/moin/AlternateLambdaSyntax

This page lists over 100 suggestions, mostly variants. So far as I can
see, my simple proposal isn't listed on that page. The page also says

> **Definitely Desirable Features**
[snip]
> *More friendly to inexperienced users*
[snip]
> Compared to other Python keywords, 'lambda' is rather esoteric.
> In the challenge for "farthest outside day-to-day English usage",
> its closest competitor would probably be 'assert', as even 'def'
> and 'elif' are just abbreviations for 'define' and 'else if'. Use of
> simpler keywords may make deferred expressions appear less
> intimidating than they seem with the current unusual keyword.

The word 'deferred' appears 7 times on the page. It also appears in
the python-dev messages.

If someone with more time and less bias then myself were to summarise
this discussion from 2006, I'd be most grateful, and they'd have
material for a great blog post.

Finally, many thanks to Abe for finding this gem, and countless
people's hard work in keeping it alive to be found. Backwards
compatibility is there for a reason.

-- 
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A simple proposal concerning lambda

[Abe Dillon]

I'm trying to dig up past threads about alternatives to lambda because I
would be astonished if "def" hadn't been considered and rejected for some
reason. What I've found so far is this unreassuring  post from Guido back
in 2006



On Tue, Aug 21, 2018 at 4:27 PM, Jonathan Fine  wrote:

> Here's what I call a simple proposal. Some people might find it
> outrageous. Today is not 1st April.
>
>
> BACKGROUND
> 
> Many Python users don't like the name lambda. But many Python users
> don't want any change here. This is true because there are millions of
> Python users, and even 100 is many. And it's hard to introduce a new
> keyword, which might break existing code. (And perhaps even worse,
> break the community.)
>
> https://wiki.python.org/moin/LocalUserGroups
> > There about 1,637 Python user groups worldwide in almost 191 cities, 37
> countries and over 860,333 members.
>
>
> SOME VALID PYTHON
> ==
> Here's some valid Python, defining two functions fn and gn, that are
> virtually identical.
>
> >>> def fn(a, b=2, c=3):
> ... return a ** b / c
> >>> fn
> 
>
> >>> gn = lambda a, b=2, c=3: a ** b / c
> >>> gn
>  at 0x7ff815e2bbf8>
>
> Notice that fn and gn have the same type, and differ by name.
>
> >>> type(fn), type(gn)
> (, )
> >>> fn.__qualname__, gn.__qualname__
> ('fn', '')
>
> And that we can modify the display name of fn and gn.
>
> >>> fn.__qualname__ = 'my_fn'
> >>> fn
> 
>
> >>> gn.__qualname__ = 'my_gn'
> >>> gn
> 
>
>
> MY SIMPLE PROPOSAL
> 
>
> Here is my simple proposal. Enhance Python to allow
>
> >>> hn = def a, b=2, c=3: a ** b / c
> >>> hn
> 
> >>> hn.__qualname__
> ''
>
> MIGRATION
> ==
>
> Migration of code would require only a keyword substitution of
> 'lambda' by 'def'.
>
> And in the docs
> 1. Note that 'def' can mean 'define' (the current use), and also
> 'defer' (evaluation of an expression).
> 2. In the first case, we have a *named function*. In the second case,
> we have an *expression function*.
>
> This idea came to me while writing:
> https://mail.python.org/pipermail/python-ideas/2018-August/052880.html
>
> --
> Jonathan
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] A simple proposal concerning lambda

[Jonathan Fine]

Here's what I call a simple proposal. Some people might find it
outrageous. Today is not 1st April.


BACKGROUND

Many Python users don't like the name lambda. But many Python users
don't want any change here. This is true because there are millions of
Python users, and even 100 is many. And it's hard to introduce a new
keyword, which might break existing code. (And perhaps even worse,
break the community.)

https://wiki.python.org/moin/LocalUserGroups
> There about 1,637 Python user groups worldwide in almost 191 cities, 37 
> countries and over 860,333 members.


SOME VALID PYTHON
==
Here's some valid Python, defining two functions fn and gn, that are
virtually identical.

>>> def fn(a, b=2, c=3):
... return a ** b / c
>>> fn


>>> gn = lambda a, b=2, c=3: a ** b / c
>>> gn
 at 0x7ff815e2bbf8>

Notice that fn and gn have the same type, and differ by name.

>>> type(fn), type(gn)
(, )
>>> fn.__qualname__, gn.__qualname__
('fn', '')

And that we can modify the display name of fn and gn.

>>> fn.__qualname__ = 'my_fn'
>>> fn


>>> gn.__qualname__ = 'my_gn'
>>> gn



MY SIMPLE PROPOSAL


Here is my simple proposal. Enhance Python to allow

>>> hn = def a, b=2, c=3: a ** b / c
>>> hn

>>> hn.__qualname__
''

MIGRATION
==

Migration of code would require only a keyword substitution of
'lambda' by 'def'.

And in the docs
1. Note that 'def' can mean 'define' (the current use), and also
'defer' (evaluation of an expression).
2. In the first case, we have a *named function*. In the second case,
we have an *expression function*.

This idea came to me while writing:
https://mail.python.org/pipermail/python-ideas/2018-August/052880.html

-- 
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/