[Python-ideas] Re: Alternate lambda syntax

[Steven D'Aprano]

On Fri, Feb 19, 2021 at 07:35:19PM +0300, Paul Sokolovsky wrote:

> People won't learn "two syntaxes for Callable". People shun using
> Python's current type annotations due to their ugliness and "quick hack
> without thinking of UX" feel. Only after there will be "int | str"
> instead of "Union[int, str]", "(int, str) -> int" instead of
> "Callable[[int, str], int]", "int & const" instead of "Annotated[int,
> const]" - only then people will start learn and use them.

Pretty much all of that is either personal subjective judgement, or 
factually untrue.

People will need to learn two syntaxes, because they will have to deal 
with legacy code using the old syntax.

People are already learning and using annotations, and have been for 
years.


> There can't be subclass of Callable in the same way as there can't be:
> 
> class my_foo(type(lambda:0)):
> pass

We can already subclass Callable.

>>> from typing import Callable
>>> class X(Callable):
... pass
... 
>>> X[1, 2]
__main__.X[1, 2]



> The difference between "(int, str) -> int" and "Callable[[int, str],
> int]" is the same as difference __str__ and __repr__.

A better analogy is the difference between a binary operator versus a 
function of two arguments:

a ^ b

bitwise_xor(a, b)

The binary operator looks nicer and is terser and more compact, but 
function notation is more self-documenting.


> "Callable" syntax
> is effectively an internal representation of the type annotation
> information.

I don't think so.


> And currently, the people have to write that verbose,
> unwieldy, ugly representation (which normally would be needed only for
> debugging purposes) manually. What we need is pleasant surface syntax
> for type annotations in Python.

I think that's nonsense. Aside from the difference between square 
brackets and round brackets, `Callable[int, str]` is just a function 
call. If you think that's "unwieldy, ugly", wait until you try writing 
some actual Python code, it is full of function calls.

It is reasonable to want a more terse and compact syntax for functions, 
but on the other hand, function parameters that take functions are 
definitely a relatively narrow niche.

More compact syntax is a Nice To Have, not a Must Have.

Paul then claims that having to write `Callable[int, str]` in an 
annotation is equivalent to writing AST:

[added indentation to make the structure easier to see]
> ---
> Module(
> body=[
> FunctionDef(
> name='foo',
> args=arguments(
> posonlyargs=[],
> args=[
> arg(arg='a')
> ],
> kwonlyargs=[],
> kw_defaults=[],
> defaults=[]
> ),
> body=[
> Expr(
> value=Call(
> func=Name(id='print', ctx=Load()),
> args=[
> Constant(value='hello')
> ],
> keywords=[]
> )
> )
> ],
> decorator_list=[]
> )
> ],
> type_ignores=[]
> )
> ---
> 
> The latter is the same as the former, just in the AST form. That's what
> we ask people to do with type annotations currently - write them in the
> AST form.

I can't take that argument seriously. How can you possibly claim that 
writing an annotation like `Callable[int, str]` is "the same as" writing 
that deeply-nested 20-line AST?



-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WX6A5RRSHJPCSP3ZFBJQIROWCOT5I44U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Caleb Donovick]

I was +0.5 on the arrow syntax for `Callable`.  It seemed like a nice short
hand but understood the arguments against it in the vain of "There should
be one-- and preferably only one --obvious way to do it."

But

>  The latter is the same as the former, just in the AST form. That's what
> we ask people to do with type annotations currently - write them in the
> AST form.

Absolutely convinced me.
+1

 - Caleb

On Fri, Feb 19, 2021 at 8:45 AM Paul Sokolovsky  wrote:

> Hello,
>
> On Sat, 20 Feb 2021 00:23:13 +0900
> "Stephen J. Turnbull"  wrote:
>
> > Abdulla Al Kathiri writes:
> >
> > Condensing to the parts which are in question,
> >
> >  > def test(self, func: t.Callable[..., bool],   *args, **kwargs) ->
> >  > Predicate: return self._build_predicate(
> >  >lambda lhs, value: func(lhs, *args, **kwargs),
> >  > Operation.TEST,
> >  > (self._path, func, args, freeze(kwargs))
> >  > )
> >
> >  > def test(self, func: (...) -> bool, *args, **kwargs) -> Predicate:
> >  > return self._build_predicate(
> >  > (lhs, value) => func(lhs, *args, **kwargs),
> >  > Operation.TEST,
> >  > (self._path, func, args, freeze(kwargs))
> >  > )
> >
> > Yes, it's nicer, but I don't see a win big enough to be worth forcing
> > people who read code to learn two syntaxes for lambda, and two
> > syntaxes for Callable (one of which isn't even syntax).
>
> People won't learn "two syntaxes for Callable". People shun using
> Python's current type annotations due to their ugliness and "quick hack
> without thinking of UX" feel. Only after there will be "int | str"
> instead of "Union[int, str]", "(int, str) -> int" instead of
> "Callable[[int, str], int]", "int & const" instead of "Annotated[int,
> const]" - only then people will start learn and use them.
>
> > Also, "->"
> > can't be just syntax, if I understand type annotations correctly.  It
> > would need to become an object constructor.
>
> It depends on how "->" in that role will be implemented. It would be
> nice to not just hardcode it to "Callable[lhs, rhs]", but at the same
> time, I'd personally hope we'll avoid yet another dunder either.
>
> >  Then the question would
> > be "are there cases where 'Callable' is not what you want there?",
> > i.e., you want a subclass of Callable.
>
> There can't be subclass of Callable in the same way as there can't be:
>
> class my_foo(type(lambda:0)):
> pass
>
> > In that case you'd have to use
> > the old syntax anyway.  (I don't have an answer to that, but you would
> > need one.)
> >
> > I don't make the rules, but to me if this is the best you can do, you
> > would have to provide evidence that quite a lot of code would benefit
> > from this.
>
> The difference between "(int, str) -> int" and "Callable[[int, str],
> int]" is the same as difference __str__ and __repr__. "Callable" syntax
> is effectively an internal representation of the type annotation
> information. And currently, the people have to write that verbose,
> unwieldy, ugly representation (which normally would be needed only for
> debugging purposes) manually. What we need is pleasant surface syntax
> for type annotations in Python.
>
> So no, __str__ vs __repr__ comparison doesn't do fairness to it. The
> difference is the same as between:
>
> ---
> def foo(a):
> print("hello")
> ---
>
> and
>
> ---
> Module(
> body=[
> FunctionDef(
> name='foo',
> args=arguments(
> posonlyargs=[],
> args=[
> arg(arg='a')],
> kwonlyargs=[],
> kw_defaults=[],
> defaults=[]),
> body=[
> Expr(
> value=Call(
> func=Name(id='print', ctx=Load()),
> args=[
> Constant(value='hello')],
> keywords=[]))],
> decorator_list=[])],
> type_ignores=[])
> ---
>
> The latter is the same as the former, just in the AST form. That's what
> we ask people to do with type annotations currently - write them in the
> AST form.
>
>
> >
> > Steve
>
>
> --
> Best regards,
>  Paul  mailto:pmis...@gmail.com
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/TC4CM3R6HKSIOOF2FNQANVLXFBOU2OZJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/C7Q5SNACJMOM55HSRP76FXPFDLXL6HOT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Paul Sokolovsky]

Hello,

On Sat, 20 Feb 2021 00:23:13 +0900
"Stephen J. Turnbull"  wrote:

> Abdulla Al Kathiri writes:
> 
> Condensing to the parts which are in question,
> 
>  > def test(self, func: t.Callable[..., bool],   *args, **kwargs) ->
>  > Predicate: return self._build_predicate(
>  >lambda lhs, value: func(lhs, *args, **kwargs),
>  > Operation.TEST,
>  > (self._path, func, args, freeze(kwargs))
>  > )   
> 
>  > def test(self, func: (...) -> bool, *args, **kwargs) -> Predicate:
>  > return self._build_predicate(
>  > (lhs, value) => func(lhs, *args, **kwargs),
>  > Operation.TEST,
>  > (self._path, func, args, freeze(kwargs))
>  > )   
> 
> Yes, it's nicer, but I don't see a win big enough to be worth forcing
> people who read code to learn two syntaxes for lambda, and two
> syntaxes for Callable (one of which isn't even syntax).

People won't learn "two syntaxes for Callable". People shun using
Python's current type annotations due to their ugliness and "quick hack
without thinking of UX" feel. Only after there will be "int | str"
instead of "Union[int, str]", "(int, str) -> int" instead of
"Callable[[int, str], int]", "int & const" instead of "Annotated[int,
const]" - only then people will start learn and use them.

> Also, "->"
> can't be just syntax, if I understand type annotations correctly.  It
> would need to become an object constructor.

It depends on how "->" in that role will be implemented. It would be
nice to not just hardcode it to "Callable[lhs, rhs]", but at the same
time, I'd personally hope we'll avoid yet another dunder either.

>  Then the question would
> be "are there cases where 'Callable' is not what you want there?",
> i.e., you want a subclass of Callable.

There can't be subclass of Callable in the same way as there can't be:

class my_foo(type(lambda:0)):
pass

> In that case you'd have to use
> the old syntax anyway.  (I don't have an answer to that, but you would
> need one.)
> 
> I don't make the rules, but to me if this is the best you can do, you
> would have to provide evidence that quite a lot of code would benefit
> from this.

The difference between "(int, str) -> int" and "Callable[[int, str],
int]" is the same as difference __str__ and __repr__. "Callable" syntax
is effectively an internal representation of the type annotation
information. And currently, the people have to write that verbose,
unwieldy, ugly representation (which normally would be needed only for
debugging purposes) manually. What we need is pleasant surface syntax
for type annotations in Python.

So no, __str__ vs __repr__ comparison doesn't do fairness to it. The
difference is the same as between:

---
def foo(a):
print("hello") 
---

and

---
Module(
body=[
FunctionDef(
name='foo',
args=arguments(
posonlyargs=[],
args=[
arg(arg='a')],
kwonlyargs=[],
kw_defaults=[],
defaults=[]),
body=[
Expr(
value=Call(
func=Name(id='print', ctx=Load()),
args=[
Constant(value='hello')],
keywords=[]))],
decorator_list=[])],
type_ignores=[])
---

The latter is the same as the former, just in the AST form. That's what
we ask people to do with type annotations currently - write them in the
AST form.


> 
> Steve


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TC4CM3R6HKSIOOF2FNQANVLXFBOU2OZJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Stephen J. Turnbull]

Abdulla Al Kathiri writes:

Condensing to the parts which are in question,

 > def test(self, func: t.Callable[..., bool],   *args, **kwargs) -> Predicate:
 > return self._build_predicate(
 >lambda lhs, value: func(lhs, *args, **kwargs),
 > Operation.TEST,
 > (self._path, func, args, freeze(kwargs))
 > ) 

 > def test(self, func: (...) -> bool, *args, **kwargs) -> Predicate:
 > return self._build_predicate(
 > (lhs, value) => func(lhs, *args, **kwargs),
 > Operation.TEST,
 > (self._path, func, args, freeze(kwargs))
 > ) 

Yes, it's nicer, but I don't see a win big enough to be worth forcing
people who read code to learn two syntaxes for lambda, and two
syntaxes for Callable (one of which isn't even syntax).  Also, "->"
can't be just syntax, if I understand type annotations correctly.  It
would need to become an object constructor.  Then the question would
be "are there cases where 'Callable' is not what you want there?",
i.e., you want a subclass of Callable.  In that case you'd have to use
the old syntax anyway.  (I don't have an answer to that, but you would
need one.)

I don't make the rules, but to me if this is the best you can do, you
would have to provide evidence that quite a lot of code would benefit
from this.

Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FE2MEP6SM4ZPAR7KAJME3KVJ6JZQLJV3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Abdulla Al Kathiri]

def test(self, func: t.Callable[..., bool],   *args, **kwargs) -> Predicate:
"""
Run a user-defined test function against the value.
>>> def test_func(val):
... return val == 42
...
>>> var('f1').test(test_func)

:param func: The function to call, passing the dict as the first
argument
:param args:
:param kwargs:
Additional arguments to pass to the test function
"""
return self._build_predicate(
   lambda lhs, value: func(lhs, *args, **kwargs),
Operation.TEST,
(self._path, func, args, freeze(kwargs))
) 

Becomes  

def test(self, func: (...) -> bool, *args, **kwargs) -> Predicate:
"""
Run a user-defined test function against the value.
>>> def test_func(val):
... return val == 42
...
>>> var('f1').test(test_func)

:param func: The function to call, passing the dict as the first
argument
:param args:
:param kwargs:
Additional arguments to pass to the test function
"""
return self._build_predicate(
(lhs, value) => func(lhs, *args, **kwargs),
Operation.TEST,
(self._path, func, args, freeze(kwargs))
) 

Sent from my iPhone

> On 19 Feb 2021, at 9:03 AM, Stephen J. Turnbull 
>  wrote:
> 
> 2qdxy4rzwzuui...@potatochowder.com writes:
>>> On 2021-02-18 at 18:10:16 +0400,
>>> Abdulla Al Kathiri  wrote:
>>> 
>>> I will be very happy if those versions of Callable and anonymous
>>> functions exist in Python right now. See how elegant that would look
>>> like..
>>> 
>>> def func(x: int, y: int, f: (int, int) -> int) -> int:
>>>return f(x, y) 
>> 
>> Elegant?  I realize that this is a contrived scenario, but even if the
>> identifiers x, y, and f were meaningful (e.g., account_balance,
>> socket_descriptor), the signal to noise ratio in that definition makes
>> me cringe.  And it only gets worse once I'm not dealing with ints.
> 
> I'm -1 on the Arrow proposal, but old Lisper that I am I do define
> functions like that.  I would write it:
> 
>def post_to_auditor(
>account_balance: PosIntPennies,
>socket_descriptor: Socket,
>validator: (PosIntPennies, Socket) -> Bool
>) -> Bool:
> 
> which I don't think is bad at all.[1]  Is the S/N really so bad?
> (Aside from the fact that try as I could I couldn't think of even one
> reason for passing both account_balance and socket_descriptor to the
> same user-supplied function, an idea that made my ears ring).
> 
> I think it's important in these things that we avoid taking toy
> examples and criticizing them for points that they weren't intended to
> make.  It's also useful to use real code to avoid this kind of
> criticism.  Most of the really strong arguments for syntax changes
> that I've seen take the stdlib, or some other large body of code (in
> this case I would bet Sympy would be a candidate) and show how the
> change improves its expressiveness.
> 
> 
> Footnotes: 
> [1]  Don't ask me about the docstring, I am a game theorist, not an
> accountant nor a network engineer.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/IHS7H5JDTROSUYEEPDYPXW7XHY45GSVO/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6D4DRQSBRYIELHY6ATIM2FJAKTQYJCUM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Stephen J. Turnbull]

2qdxy4rzwzuui...@potatochowder.com writes:
 > On 2021-02-18 at 18:10:16 +0400,
 > Abdulla Al Kathiri  wrote:
 > 
 > > I will be very happy if those versions of Callable and anonymous
 > > functions exist in Python right now. See how elegant that would look
 > > like..
 > > 
 > > def func(x: int, y: int, f: (int, int) -> int) -> int:
 > >return f(x, y) 
 > 
 > Elegant?  I realize that this is a contrived scenario, but even if the
 > identifiers x, y, and f were meaningful (e.g., account_balance,
 > socket_descriptor), the signal to noise ratio in that definition makes
 > me cringe.  And it only gets worse once I'm not dealing with ints.

I'm -1 on the Arrow proposal, but old Lisper that I am I do define
functions like that.  I would write it:

def post_to_auditor(
account_balance: PosIntPennies,
socket_descriptor: Socket,
validator: (PosIntPennies, Socket) -> Bool
) -> Bool:

which I don't think is bad at all.[1]  Is the S/N really so bad?
(Aside from the fact that try as I could I couldn't think of even one
reason for passing both account_balance and socket_descriptor to the
same user-supplied function, an idea that made my ears ring).

I think it's important in these things that we avoid taking toy
examples and criticizing them for points that they weren't intended to
make.  It's also useful to use real code to avoid this kind of
criticism.  Most of the really strong arguments for syntax changes
that I've seen take the stdlib, or some other large body of code (in
this case I would bet Sympy would be a candidate) and show how the
change improves its expressiveness.


Footnotes: 
[1]  Don't ask me about the docstring, I am a game theorist, not an
accountant nor a network engineer.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IHS7H5JDTROSUYEEPDYPXW7XHY45GSVO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Greg Ewing]

On 19/02/21 9:43 am, Steven D'Aprano wrote:

Although I have heard from Ruby enthusiasts that the ability to write
large, complex, multi-statement anonymous block functions is really
useful, its not something I can personally say I have missed.


Ruby may be somewhat different here, because Ruby's equivalent
of things like the iterator protocol work by passing in a block
of code representing the loop body, so having an easy way to
write that is important.

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OWJSH7YOKDASTILTGNMPW4YTBGV3SZPU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[David Mertz]

On Thu, Feb 18, 2021 at 8:46 PM Steven D'Aprano  wrote:

> Although I have heard from Ruby enthusiasts that the ability to write
> large, complex, multi-statement anonymous block functions is really
> useful, its not something I can personally say I have missed.
> I think that once you get past a fairly simple one-line expression,
> anything else ought to be tested; and that requires making it a named
> function at the top level so that doctest or unittest can see it.
>

I think I can kinda sympathize with that perspective.  Just like you
sometimes have an elif block where "a bunch of stuff happens", sometimes
you have a callback function that is only used by one other function.  It
cannot be a block in current Python because it's a callback, but it doesn't
*really* have a meaningful name outside that of the enclosing function.

On other hand, writing an inner function and using the throwaway name `fn`
for it requires two extra characters.  OK, maybe 4 characters since it is
both defined and then used.  Of course, exact character count depends on
the hypothetical syntax of a "multi-statement lambda" ... but it amounts to
"no big deal" in existing Python, in any case.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/I6DZPPDI6KPAOS573VWNLUZE6TP7LUTP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Steven D'Aprano]

On Wed, Feb 17, 2021 at 07:03:55PM +, Gustavo Carneiro wrote:

> Just my 2c, I don't find lambda verbose at all, quite like it.
> 
> But I wish Python allowed for multi-line lambda functions... somehow.

Python allows for multi-*line* lambda:

  lambda key, value, condition, sep='', default='': (
compute_prefix(key) 
+ sep.join([str(expression or default)
for obj in lookup(key, value)
if condition(obj)]
  )
+ compute_suffix(key)
)

What it doesn't allow is multi-*statement* lambda; lambda is limited to 
a single expression.

Although I have heard from Ruby enthusiasts that the ability to write 
large, complex, multi-statement anonymous block functions is really 
useful, its not something I can personally say I have missed.

I think that once you get past a fairly simple one-line expression, 
anything else ought to be tested; and that requires making it a named 
function at the top level so that doctest or unittest can see it.


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AWP6IPKTD6WYTBUCHZ4NWD2MJ6OLZLQ3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[2QdxY4RzWzUUiLuE]

On 2021-02-18 at 18:10:16 +0400,
Abdulla Al Kathiri  wrote:

> I will be very happy if those versions of Callable and anonymous
> functions exist in Python right now. See how elegant that would look
> like..
> 
> def func(x: int, y: int, f: (int, int) -> int) -> int:
>   return f(x, y) 

Elegant?  I realize that this is a contrived scenario, but even if the
identifiers x, y, and f were meaningful (e.g., account_balance,
socket_descriptor), the signal to noise ratio in that definition makes
me cringe.  And it only gets worse once I'm not dealing with ints.

> print(func(3, 4, (x, y) => x + y)) #Out: 7
> 
> Imagine your mouse is on :func: ‘func’ in VSC or PyCharm and see that
> you need the third parameter to be of type (int, int) -> int, you can
> immediately write an anonymous function that mirrors the structure of
> the annotation but instead of ->, you have =>. Straight forward.

If my IDE is that clever, then it can also type "lambda x, y: " for me
in addition to showing me that signature.

Aside:  And then a thousand developers/engineers/maintainers, auditors,
and testers (not to mention future me) have to read that anonymous
function.  Over and over.  And over.  Unless it's trivial, or simpler,
use a def statement, give it a name and a doc string, test it, and reuse
it.  And if it's that trivial, then trading "lambda" for "->" (or "=>")
doesn't matter.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4QNOE7AFAAYWZWQQJ24GCUMFVX2JBI4F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Abdulla Al Kathiri]

I will be very happy if those versions of Callable and anonymous functions 
exist in Python right now. See how elegant that would look like.. 

def func(x: int, y: int, f: (int, int) -> int) -> int:
return f(x, y) 

print(func(3, 4, (x, y) => x + y)) #Out: 7


Imagine your mouse is on :func: ‘func’ in VSC or PyCharm and see that you need 
the third parameter to be of type (int, int) -> int, you can immediately write 
an anonymous function that mirrors the structure of the annotation but instead 
of ->, you have =>. Straight forward.

> On 18 Feb 2021, at 12:43 PM, Paul Sokolovsky  wrote:
> 
> (x, y) -> x + ytranslates to:   Callable[[x, y], x + y]
> 
> while
> 
> (x, y) => x + ytranslates to:   lambda x, y: x + y
> 
> Huge difference.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/V7KSM464X2ECGWUQFZ5OH4A74LIHF4HG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Paul Sokolovsky]

Hello,

On Wed, 17 Feb 2021 18:43:09 -0300
"Joao S. O. Bueno"  wrote:

> On Wed, 17 Feb 2021 at 18:15, Abdulla Al Kathiri <
> alkathiri.abdu...@gmail.com> wrote:  
> 
> > How is this not pythonic?
> >
> > series.apply(x -> x**2)
> > Compared to..
> > series.apply(lambda x: x**2)
> >
> >
> > (x, y) -> x+y, () -> 0, (x) -> x**2 (for single parameter, we can
> > write it without parenthesis like the example above) are pythonic
> > enough to my eyes.

As said many times already, that's not Pythonic, because "->" is used
in Python for return *type* annotation, and thus cannot be used as
lambda synonym (without hampering understandability for machines and
humans).

To illustrate it,

(x, y) -> x + ytranslates to:   Callable[[x, y], x + y]

while

(x, y) => x + ytranslates to:   lambda x, y: x + y

Huge difference.

> Well, for m eyes, the above is definetellly  "perlonic" . it could be
> "j" before being Pyrhon.

That's unlikely, in Perl it would be something like $x+$y $) ql/x y/.

As was said from the very beginning, "(x, y) => x + y" is
"JavaScriptonic". For reference, JavaScript is the world's leading
programming language, and now even turned out that it has some "good
parts" (much later than originally supposed). So, people are looking
how to "steal" those good parts. (Just the same as previously, JS
"stole" generators from Python).


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MRNRM777SG5L5W6QMVUSKHJDCUYUKNCV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Stephen J. Turnbull]

Abdulla Al Kathiri writes:

 > How is this not pythonic? 
 > 
 > series.apply(x -> x**2)
 > Compared to.. 
 > series.apply(lambda x: x**2)

The main problem is that the second already exists, and the first
doesn't, while the first adds no new power to the language, and isn't
enough more readable (and some would argue less readable, expecially
in the multiple "lots of irritating parentheses" form) than the
"lambda" version.  While it's not a good idea to take the Zen too
seriously, "There should be one-- and preferably only one --obvious
way to do it." is often good advice.  "Although that way may not be
obvious at first unless you're Dutch." means that often that way must
be taught to most developers, with "lambda" being an extreme case
since very few of us come from the Lisp, Haskell, or Mathematical
Logic worlds any more, so references to lambda are infrequent.

A small issue is that with a different value, "f(x -> V)" is also
possibly a typo for "f(x) -> V", and likely to occur if you have
automagic parenthesis matching in your editor.

In general, Python's designers prefer (and try to encourage) a style
emphasizing building up complex applications from relatively small
*named* functions, rather than large monolithic blocks of code.
Random's cavil about warty keywords notwithstanding, I kinda like my
idea of using a "def expression" to pass a local function as a keyword
argument.  I wouldn't be surprised if Guido pops up to say "I thought
of that in 1998, but it was too cute by half", though. :-)

One could argue that this fits the typical human brain well, with its
ability to handle chunked data in groups of 7 +/- 2 items.  It's
unarguable that Python has become very popular, and that its fans are
quite devoted to it.  Something about this style is capturing them!

I don't speak for Guido or any other authoritative voices, that's just
my take.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OQMNNXJZR67SHPCJZ7YJ42ZQY26OVIWB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Greg Ewing]

On 18/02/21 3:38 am, MRAB wrote:


So a "byte" is part of a word (a word contains multiple characters).


In the Burroughs B6900 architecture, programs consisted
of 48-bit words broken up into 8-bit opcodes called "syllables".

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PCD2BLQSUX2AQY43PFFCEQTOILFLSYX4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Abdulla Al Kathiri]

Those are not anonymous functions though. 

> On 18 Feb 2021, at 1:43 AM, Joao S. O. Bueno  wrote:
> 
> def f1(x, y): 
>return x + y
> 
> def f2():
>   return 0
> 
> def f3(x):
>return x ** 2
> 

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/S2BT2WJ5GX3MFGCY5YK2D6DWIAA7V3NW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Joao S. O. Bueno]

On Wed, 17 Feb 2021 at 18:15, Abdulla Al Kathiri <
alkathiri.abdu...@gmail.com> wrote:

> How is this not pythonic?
>
> series.apply(x -> x**2)
> Compared to..
> series.apply(lambda x: x**2)
>
>
> (x, y) -> x+y, () -> 0, (x) -> x**2 (for single parameter, we can write it
> without parenthesis like the example above) are pythonic enough to my eyes.
>

Well, for m eyes, the above is definetellly  "perlonic" . it could be "j"
before being Pyrhon.

This is Pythonic:

def f1(x, y):
   return x + y

def f2():
  return 0

def f3(x):
   return x ** 2


And it took me a while looking at our example to check it was not really
fuction composition with
default parameters, or what.

I mentioned violation of 6 of the first 7 phrases in the famous "zen of
Python" -
most important of which can be reasonably agreed is the 7th: "Readability
counts".

If you don't want readability at all in exchange for typing a few keywords
(which more and more automatic tools can auto-complete), I'd suggest going
for the "forth" language.




Abdulla
>
> On 17 Feb 2021, at 10:59 PM, Joao S. O. Bueno 
> wrote:
>
> If someone comes with a "pythonic" way to lift restrictions on
> lambda, that could be something for debate, but so far this is
> just about uglifying it, and creating a new syntax matching
> exactly what exists today.
>
>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GL4TPNMIDZTH63WO6E6QNZX57NGYZH2L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Abdulla Al Kathiri]

How is this not pythonic? 

series.apply(x -> x**2)
Compared to.. 
series.apply(lambda x: x**2)


(x, y) -> x+y, () -> 0, (x) -> x**2 (for single parameter, we can write it 
without parenthesis like the example above) are pythonic enough to my eyes. 

Abdulla

> On 17 Feb 2021, at 10:59 PM, Joao S. O. Bueno  wrote:
> 
> If someone comes with a "pythonic" way to lift restrictions on
> lambda, that could be something for debate, but so far this is
> just about uglifying it, and creating a new syntax matching
> exactly what exists today.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EK62X73EIH776XGDWUWSN4GWFXDEFD22/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Gustavo Carneiro]

On Wed, 17 Feb 2021 at 18:30, Ethan Furman  wrote:

> On 2/17/21 8:47 AM, Random832 wrote:
> > On Tue, Feb 16, 2021, at 23:24, Stephen J. Turnbull wrote:
>
> >> except a couple of characters.  So what currently looks like
> >>
> >>  some_list.sort(key=lambda e: e[3].priority)
> >>
> >> would then be
> >>
> >>  some_list.sort(key=(e)->e[3].priority)
> >
> > Let's not pretend the key argument being keyword-only isn't a wart.
> Surely this would be better if it could be some_list.sort(e->e[3].priority).
>
> No need to pretend, it isn't a wart.
>
> -1 on removing the lambda keyword.  Just because excessive punctuation
> works for other languages does not mean it's a good fit for Python.
>

Just my 2c, I don't find lambda verbose at all, quite like it.

But I wish Python allowed for multi-line lambda functions... somehow.

Why? If you need to have a callback function that takes 2 to 5 lines of
code, then
   (1) current lambda doesn't allow it,
   (2) inline named function, defined earlier, is too verbose IMHO (code
style dictates it needs two blank lines, one before, one after, plus need
to have a name),
 and also somewhat breaks the flow of reading code.

A multi-line lambda would be able to fill the gap, between too big for
single line lambda, but too small to justify its own def xxx().

Sorry, I don't have any concrete proposal, just a vague wish.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PSWFL5AQLWAQSDJA2M2IMZBUPQGCL5NB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Joao S. O. Bueno]

On Wed, 17 Feb 2021 at 15:31, Ethan Furman  wrote:

> On 2/17/21 8:47 AM, Random832 wrote:
> > On Tue, Feb 16, 2021, at 23:24, Stephen J. Turnbull wrote:
>
> >> except a couple of characters.  So what currently looks like
> >>
> >>  some_list.sort(key=lambda e: e[3].priority)
> >>
> >> would then be
> >>
> >>  some_list.sort(key=(e)->e[3].priority)
> >
> > Let's not pretend the key argument being keyword-only isn't a wart.
> Surely this would be better if it could be some_list.sort(e->e[3].priority).
>
> No need to pretend, it isn't a wart.
>
> -1 on removing the lambda keyword.  Just because excessive punctuation
> works for other languages does not mean it's a good fit for Python.
>
> Indeed - I think typing `import this` is enough to see that this change
would directly contradict 6 of the first 7 guidelines in the zen.

If someone comes with a "pythonic" way to lift restrictions on
lambda, that could be something for debate, but so far this is
just about uglifying it, and creating a new syntax matching
exactly what exists today.

Moreover I'd like to remind people so much worried about
expressiveness in less and less characters that Lambda is
much less needed in Python than in similar languages due
to the existence of the comprehensions and generator expression
constructs.

The energy spent here could be focused instead on having an
equivalent of comprehensions for "reduce", for example.

> --
> ~Ethan~
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/IU7DEE5WZFWDKFDPUZAYCV5DPGFGSAJK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/POJMDVA5WPCOXJUHCQPPK5ZE6ZW6GOXM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Ethan Furman]

On 2/17/21 8:47 AM, Random832 wrote:

On Tue, Feb 16, 2021, at 23:24, Stephen J. Turnbull wrote:



except a couple of characters.  So what currently looks like

 some_list.sort(key=lambda e: e[3].priority)

would then be

 some_list.sort(key=(e)->e[3].priority)


Let's not pretend the key argument being keyword-only isn't a wart. Surely this 
would be better if it could be some_list.sort(e->e[3].priority).


No need to pretend, it isn't a wart.

-1 on removing the lambda keyword.  Just because excessive punctuation 
works for other languages does not mean it's a good fit for Python.


--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IU7DEE5WZFWDKFDPUZAYCV5DPGFGSAJK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Random832]

On Tue, Feb 16, 2021, at 23:24, Stephen J. Turnbull wrote:
> except a couple of characters.  So what currently looks like
> 
> some_list.sort(key=lambda e: e[3].priority)
> 
> would then be
> 
> some_list.sort(key=(e)->e[3].priority)

Let's not pretend the key argument being keyword-only isn't a wart. Surely this 
would be better if it could be some_list.sort(e->e[3].priority).

> which is shorter but not particularly more readable (and already has a
> familiar meaning in C-like languages).

this side point is an argument in favor of using => instead.

[and if => can be confused with >=, surely so can -> be confused with >-]

> 1.  In a one-line def of the form "def foo([arglist]): return EXPR",
> "return" may be omitted, and the function returns the value of
> EXPR (rather than None as currently).  (As a multiline def, EXPR
> would be presumed to be evaluated for side effects, and 

I would like something like this - it's worth noting that C# [and as someone 
helpfully pointed out, Dart] uses => for this case as well, and the argument 
about the syntax looking bad when a return type annotation is present is, I 
think, overblown - return type annotations are almost never needed for a 
function with a single return statement.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BHH7EIXT7KSFMBGTSGG6VKWKD55Y2TE4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[MRAB]

On 2021-02-17 05:57, Steven D'Aprano wrote:

On Wed, Feb 17, 2021 at 11:13:08AM +1300, Greg Ewing wrote:

On 17/02/21 7:10 am, Steven D'Aprano wrote:
>"It's Greek letter, like pi that you may remember from maths
>class. In some technical computer science, the Greek L, lambda, is used
>as the symbol for functions."

The most accurate answer seems to be "Because somebody made
a mistake transcribing a mathematics paper many years ago." :-)


Not according to Alonzo Church, who at various times has stated that it
was either more or less chosen at random, or that it was derived from
Whitehead and Russell's x̂ (x-hat) via ∧x to λx to make it easier for the
printers.

Either way it wasn't a mistake, but a deliberate choice.

It is really remarkable how much attention lambda gets. As far as I
know, mathematicians don't ask why Hilbert chose epsilon for his epsilon
calculus, and nobody ever asks where "byte" comes from.

It is, apparently, a deliberate misspelling of bite, to avoid it being
accidently changed to bit. But why *bite*?

The first published use of "byte" apparently was in a 1956 IBM memo by
Werner Buchholz:

"[…] Most important, from the point of view of editing, will be the
ability to handle any characters or digits, from 1 to 6 bits long.
Figure 2 shows the Shift Matrix to be used to convert a 60-bit word,
coming from Memory in parallel, into characters, or 'bytes' as we have
called them, to be sent to the Adder serially."

The memo already shows that Buchholz and IBM were thinking of
multiple bits being a "word", so it's not clear why bytes. There's no
ordinary sense that a collection of bits (as in "a bit of stuff") is
considered "a bite".

It's like eating a sausage. You start at one end and take bites off it 
until you've eaten it all.


So a "byte" is part of a word (a word contains multiple characters).


Language is fun.


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PGRWOZJMKJBMQ7VYY7ATXXKBVRLCISUM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Steven D'Aprano]

On Wed, Feb 17, 2021 at 11:13:08AM +1300, Greg Ewing wrote:
> On 17/02/21 7:10 am, Steven D'Aprano wrote:
> >"It's Greek letter, like pi that you may remember from maths
> >class. In some technical computer science, the Greek L, lambda, is used
> >as the symbol for functions."
> 
> The most accurate answer seems to be "Because somebody made
> a mistake transcribing a mathematics paper many years ago." :-)

Not according to Alonzo Church, who at various times has stated that it 
was either more or less chosen at random, or that it was derived from 
Whitehead and Russell's x̂ (x-hat) via ∧x to λx to make it easier for the 
printers.

Either way it wasn't a mistake, but a deliberate choice.

It is really remarkable how much attention lambda gets. As far as I 
know, mathematicians don't ask why Hilbert chose epsilon for his epsilon 
calculus, and nobody ever asks where "byte" comes from.

It is, apparently, a deliberate misspelling of bite, to avoid it being 
accidently changed to bit. But why *bite*?

The first published use of "byte" apparently was in a 1956 IBM memo by 
Werner Buchholz:

"[…] Most important, from the point of view of editing, will be the 
ability to handle any characters or digits, from 1 to 6 bits long. 
Figure 2 shows the Shift Matrix to be used to convert a 60-bit word, 
coming from Memory in parallel, into characters, or 'bytes' as we have 
called them, to be sent to the Adder serially."

The memo already shows that Buchholz and IBM were thinking of 
multiple bits being a "word", so it's not clear why bytes. There's no 
ordinary sense that a collection of bits (as in "a bit of stuff") is 
considered "a bite".

Language is fun.


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SAIVWEGHB33IV6UM5JN2U2C333U4P6PP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Stephen J. Turnbull]

Ned Batchelder writes:

 > "lambda" is unnecessarily obscure.

And it should be.  It's really only useful as an argument.  There's no
advantage to

foo = (x) -> 1

vs.

def foo(x): return 1

except a couple of characters.  So what currently looks like

some_list.sort(key=lambda e: e[3].priority)

would then be

some_list.sort(key=(e)->e[3].priority)

which is shorter but not particularly more readable (and already has a
familiar meaning in C-like languages).  It seems to me that two
changes to def might be considered:

1.  In a one-line def of the form "def foo([arglist]): return EXPR",
"return" may be omitted, and the function returns the value of
EXPR (rather than None as currently).  (As a multiline def, EXPR
would be presumed to be evaluated for side effects, and 

2.  As an actual argument, a one-line def is interpreted not as a
positional argument, but as a keyword argument, so that in

some_list.sort(def key(e): e[3].priority)

the name "key" is not optional, and must match a keyword argument.

I suggest 1 for "ordinary" defs as well for consistency, but evidently
we could also restrict that usage to "def as keyword argument", and
maintain backwards compatibility.

2 could even be independent of 1:

some_list.sort(def key(e): return e[3].priority)

but that seems excessively verbose.

Another possible use case would be in a for loop:

for fun in [def fun(): return 1,
def fun(): return 2,
def fun(): return 3]:
do_something_with(fun)

where similarly the loop variable needs to match the def.

 > Beginner: "why is it called lambda?"
 > 
 > Teacher: "Don't worry about it, just use it to define a function"
 > 

It me.  But it would go like this:

Teacher [face lights up at the chance to talk math history]: "You see, ..."

Students [in harmony]: "Nooo.. :-(" [collective sigh]

Regards,
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2UQU33XFZFMNP4AITJXQJI3UNPYTEOW7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[M.-A. Lemburg]

On 16.02.2021 23:13, Greg Ewing wrote:
> On 17/02/21 7:10 am, Steven D'Aprano wrote:
>> "It's Greek letter, like pi that you may remember from maths
>> class. In some technical computer science, the Greek L, lambda, is used
>> as the symbol for functions."
> 
> The most accurate answer seems to be "Because somebody made
> a mistake transcribing a mathematics paper many years ago." :-)

The Python notation for anonymous function is almost a direct
reference to the original notation for such functions in
lambda calculus:

λx.x+1 ... lambda x: x+1

I think that's an excellent hint for students to look up on this
great piece of mathematical logic:

https://en.wikipedia.org/wiki/Lambda_calculus

and learn something about the foundations of computer science.

Why the Greek letter lambda ? Who knows -- mathematicians love
Greek letters, logic is λογική in Greek, ...

https://en.wikipedia.org/wiki/Lambda_calculus#Origin_of_the_lambda_symbol

And, of course, if you don't like anonymous functions, you're
always free to give your functions names in Python ;-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Feb 17 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CRHVZBRDAY6M2HOWGXX6REWQWTTHFFSF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Steven D'Aprano]

On Wed, Feb 17, 2021 at 01:03:40AM +0400, Abdulla Al Kathiri wrote:

> From Wikipedia:
> "The term originated as an abstraction of the sequence: single, 
> couple/double, triple, quadruple, quintuple, sextuple, septuple, 
> octuple, ..., n‑tuple, …"

And that's so obvious in hindsight. Thank you.



-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OW72BO43HECV7H6EEW7PA43C3O5T6ORS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Greg Ewing]

On 17/02/21 7:10 am, Steven D'Aprano wrote:

Its no more "magic" than tuple, deque, iterator,
coroutine, ordinal, modulus, etc, not to mention those ordinary English
words with specialised jargon meanings like float, tab, zip, thread,
key, promise, trampoline, tree, hash etc.


Actually, I think it is -- all those words build on a pre-existing
meaning in some way, and in most cases you can trace the etymology
back to something the person is most likely already familiar with.
Lambda, on the other hand, is a completely fresh arbitrary choice.

I agree that the technical meaning has to be taught in any case,
though.

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WBTJLJ4NSARXBPJM4VYSJRVFIRT2DQHW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Greg Ewing]

On 17/02/21 7:10 am, Steven D'Aprano wrote:

"It's Greek letter, like pi that you may remember from maths
class. In some technical computer science, the Greek L, lambda, is used
as the symbol for functions."


The most accurate answer seems to be "Because somebody made
a mistake transcribing a mathematics paper many years ago." :-)

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UW6436X65TGMC4D5ROIW4MH7GYUJQS5L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Abdulla Al Kathiri]

From Wikipedia:
"The term originated as an abstraction of the sequence: single, couple/double, 
triple, quadruple, quintuple, sextuple, septuple, octuple, ..., n‑tuple, …"

> On 16 Feb 2021, at 10:10 PM, Steven D'Aprano  wrote:
> 
> And I still 
> don't know where the word comes from in the first place. Given that it 
> is used in maths, probably Latin, Greek or Arabic.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2XJSJI5D3VFVDOWAGYANBPD7EFTZ62MD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Steven D'Aprano]

On Tue, Feb 16, 2021 at 11:38:33AM -0500, Ned Batchelder wrote:

> "lambda" is unnecessarily obscure.
> 
> Beginner: "why is it called lambda?"
> 
> Teacher: "Don't worry about it, just use it to define a function"

That's a bad answer. A better answer that is more appropriate for nearly 
everyone is "It's Greek letter, like pi that you may remember from maths 
class. In some technical computer science, the Greek L, lambda, is used 
as the symbol for functions."

Two sentences, a few seconds to say.

At this point the student almost certainly will be either satisfied with 
the answer, and have learned something new, or will be satisfied with 
the fact that there is an answer, and promptly forget it because they 
didn't really care, they just want to know that there is a reason.

And for that perhaps one in fifty who go on to ask "Why lambda?", the 
answer is "They had to choose some letter, and lambda was the one they 
picked."

I don't understand people who are unwilling to explain things. It makes 
me sad.


> I'm not taking a side on whether to change Python, but let's please not 
> lose sight of just how opaque the word "lambda" is. People who know the 
> background of lambda can easily understand using a different word.  
> People who don't know the background are presented with a "magic word" 
> with no meaning.  That's not good UI.

You know the approximately 7.4 billion people in the world who aren't 
native English speakers? And the approximately 5 billion people who 
speak no English at all? They just said "Welcome to our world!"

Honestly, I think this argument about lambda being a magic word is both 
privileged and silly. Its no more "magic" than tuple, deque, iterator, 
coroutine, ordinal, modulus, etc, not to mention those ordinary English 
words with specialised jargon meanings like float, tab, zip, thread, 
key, promise, trampoline, tree, hash etc. It's just a word. Every single 
word that we know had "no meaning" to us at some point. None of us were 
born knowing what "raise" or "hex" means.

There is a *ton* of jargon to learn on the way to becoming a decent 
programmer, I don't know why lambda is singled out for so much hate. 
Personally I had much more difficulty learning "tuple", or "turple" as I 
insisted on spelling it for about the first five years. And I still 
don't know where the word comes from in the first place. Given that it 
is used in maths, probably Latin, Greek or Arabic.


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XQXLIZTJ33MXNJ5KZB6OBLVFQQH25XIM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Paul Moore]

On Tue, 16 Feb 2021 at 16:40, Ned Batchelder  wrote:
>
> "lambda" is unnecessarily obscure.
>
> Beginner: "why is it called lambda?"
>
> Teacher: "Don't worry about it, just use it to define a function"
>
> I'm not taking a side on whether to change Python, but let's please not
> lose sight of just how opaque the word "lambda" is. People who know the
> background of lambda can easily understand using a different word.
> People who don't know the background are presented with a "magic word"
> with no meaning.  That's not good UI.

Agreed. When lambda was introduced, "anonymous functions" were not as
common in programming, and the most obvious example of their usage was
in lisp, where "lambda" was the accepted term. Since then, lisp has
not gained much additional popularity, but anonymous functions have
appeared in a number of mainstream languages. The syntax is typically
some form of "a, b -> a+b" style, and *never* uses the term "lambda".
So someone coming to Python with any familiarity with other languages
will now find Python's form atypical and obscure. People coming with
no experience of other languages will need to have a history lesson to
understand why the term is "lambda" rather than "something more
obvious".

People can, and will, learn Python's syntax. This isn't a major
disaster. But if this were a new feature, we'd not be having this
discussion, and "lambda" wouldn't even be a consideration.

I'm also not taking a side on whether a change is worth the
disruption. Personally, I prefer the arrow syntax, but we're not
making a decision in a vacuum here. Someone has to make a case
(probably in a PEP) if this is going to change, and the trade-offs
should be clarified there.

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/M25C6O55JCYLFOUW7DPPFGAETVOGN6R5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Ned Batchelder]

"lambda" is unnecessarily obscure.

Beginner: "why is it called lambda?"

Teacher: "Don't worry about it, just use it to define a function"

I'm not taking a side on whether to change Python, but let's please not 
lose sight of just how opaque the word "lambda" is. People who know the 
background of lambda can easily understand using a different word.  
People who don't know the background are presented with a "magic word" 
with no meaning.  That's not good UI.


--Ned.

On 2/14/21 11:39 AM, Paul Sokolovsky wrote:

Hello,

On Sat, 13 Feb 2021 14:33:43 -0800
Christopher Barker  wrote:


There seems to be a frequent objection to the word "lambda" --
personally, I found it cryptic, but it's not hard to remember, and it
IS easy to look up.

There seems to be a bit too many posts downputting the "lambda"
keyword, and nobody went for its defense, so let me do that. The
"lambda" is perhaps the greatest thing in Python after... after...
well, maybe it's the single greatest thing in Python.

As someone coming to Python from LISP (many years ago), I really
appreciate it, and always considered Python to be "a LISP for real
world".

So, it's of great utility to people familiar with functional
programming, but even of more utility to novices who are not yet -
thanks to it, by looking it up, they can get acquainted with the
wonderful world of functional programming and history of programming
languages.

Lambda is a sacred keyword, please don't touch!


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DVCY2WHPO3N5R4I325ETOZUVBBZOJS7I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Rob Cliffe via Python-ideas]

On 15/02/2021 19:47, Mike Miller wrote:


On 2021-02-13 14:33, Christopher Barker wrote:
On Fri, Feb 12, 2021 at 1:00 AM Brendan Barnwell 
mailto:brenb...@brenbarn.net>> wrote:
         The only thing that would be better than lambda is a 
less confusing

    keyword.
There seems to be a frequent objection to the word "lambda" -- 
personally, I found it cryptic, but it's not hard to remember, and it 
IS easy to look up. But if you don't like that word, why not "def"? 
Every place I've tried to use "def" where "lambda" is legal, it's a 
syntax error. So we could use the same word. Would that be less 
confusing?



Agreed.  It isn't too important at this point, but I'd also skip the 
punctuation and add an expression version of def:



    def named_function(x, y):
    return x * y

    anonymous_function = def x, y: x * y

That seems sensible, if there is no syntactical ambiguity.



Parentheses on the parameter list could be allowed as well.

Yes please!  That is a feature of Python 2 that I miss in Python 3.




Javascript has (too much) flexibility in this area, but I wouldn't 
mind Python loosening slightly to use the keyword it probably should 
have in the beginning.


-Mike

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YHVQIVD6AZFANODLEBMVLNOTGWKK6GZ3/

Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2LF7NSNNEYFTH5CTNE7BUDCUNO5T6QCI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Mike Miller]

On 2021-02-13 14:33, Christopher Barker wrote:
On Fri, Feb 12, 2021 at 1:00 AM Brendan Barnwell > wrote:

         The only thing that would be better than lambda is a less confusing
keyword. 

There seems to be a frequent objection to the word "lambda" -- personally, I 
found it cryptic, but it's not hard to remember, and it IS easy to look up. But 
if you don't like that word, why not "def"? Every place I've tried to use "def" 
where "lambda" is legal, it's a syntax error. So we could use the same word. 
Would that be less confusing?



Agreed.  It isn't too important at this point, but I'd also skip the punctuation 
and add an expression version of def:



def named_function(x, y):
return x * y

anonymous_function = def x, y: x * y


Parentheses on the parameter list could be allowed as well.

Javascript has (too much) flexibility in this area, but I wouldn't mind Python 
loosening slightly to use the keyword it probably should have in the beginning.


-Mike

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YHVQIVD6AZFANODLEBMVLNOTGWKK6GZ3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Christopher Barker]

On Sun, Feb 14, 2021 at 4:26 AM Serhiy Storchaka 
wrote:

> Lambda is a questionable feature at all. With support of comprehensions,
> local functions, the operator and functools modules there are not many
> use cases for lambda expression. They are supported, well, but it is not
> significant part of the language.
>

Thank you -- I'm not quite sure they are "questionable", but they do have
limited use in the language, and far less use then they did back in the
early days of Python. In fact, most of the uses I've seen of lambda in
recent code (particularly from newbies) is totally unnecessary.

If the only thing this proposal is about is a way to create small anonymous
functions without using the keyword "lambda" -- it is pretty darn pointless.

And frankly, this compact notation is a lot harder (for me at least) to
parse at a glance -- "lambda" may be a strange and confusing word for
newbies, but it's easy to look up, and it's really obvious that *something*
is going on there. Whereas parentheses are used all over the place, and are
often optional. And more "line noise"-like symbols like => isn't really
going to help.

In fact, I've only written a smattering of C, but it still requires some
extra thinking to identify where a function is being defined -- a keyword
(like def) would be so much more clear to me.

Final point:

Python has been around a long time, there's a lot of code already written
-- any changes to syntax should only be ones that add real functionality or
expressiveness -- a slightly-easier-to-write (and maybe read) anonymous
function syntax is nowhere near that threshold.

-Chris B

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/U4P4CX7Q2RTV6BSPMWY2TD7LA53EPSYF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Paul Sokolovsky]

Hello,

On Sat, 13 Feb 2021 14:33:43 -0800
Christopher Barker  wrote:

> There seems to be a frequent objection to the word "lambda" --
> personally, I found it cryptic, but it's not hard to remember, and it
> IS easy to look up.

There seems to be a bit too many posts downputting the "lambda"
keyword, and nobody went for its defense, so let me do that. The
"lambda" is perhaps the greatest thing in Python after... after...
well, maybe it's the single greatest thing in Python.

As someone coming to Python from LISP (many years ago), I really
appreciate it, and always considered Python to be "a LISP for real
world".

So, it's of great utility to people familiar with functional
programming, but even of more utility to novices who are not yet -
thanks to it, by looking it up, they can get acquainted with the
wonderful world of functional programming and history of programming
languages.

Lambda is a sacred keyword, please don't touch! 

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OQ77ILWZERPL27U5A5BDH3YOYFW3DIRM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Steven D'Aprano]

Be bold, they say...


On Mon, Feb 15, 2021 at 02:13:38AM +1100, Steven D'Aprano wrote:

> If I'm wrong, I'm sure somebody will point that out. I'm not frightened 
> of making bold claims that turn out to be wrong: that just means I have 
> learned something new. (Or something old that I forgot.)

Okay, there is an ambiguity, if arrow function syntax includes 
annotations with the syntax I suggested. I had:

(values:List[float], arg:int=0 -> Type) -> expression

Using that syntax, there is an ambiguous case:

(arg=(a, b) -> T) -> expression

That could mean:

* Default value of arg is the arrow function `(a, b) -> T`;

* Or the default value of arg is the tuple `(a, b)`, and the arrow 
  function has the return type T.

This may suggest that, like lambda, we should just not allow annotations 
in arrow functions; or that we need a better way to include the return 
annotation.

The third fix is to use `=>` for the arrow functions, but this has many 
down-sides, as previously discussed.

Anyway, the rest of my claim still stands (I think): if arrow functions 
don't include annotations there is no ambiguity between function 
annotations and arrow functions.


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FFXEX54RWDCWEZ2D2DENQEZCZ2WYVGWJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Steven D'Aprano]

On Sun, Feb 14, 2021 at 11:23:59AM +0300, Paul Sokolovsky wrote:

> > We've seen Paul mistake => for >= and he's not the only one.
> 
> Well, my mistake is based on the fact that I don't spend high-level
> neurons on remembering mundane low-level things, like order of
> characters if the "greater or equals" operator. Instead, low-level
> hands motor function neurons get it right when I type (most of the time
> ;-)).

That would be just great if code was written more than it is read.

("Doesn't matter that people reading the code confusion the symbols, 
nobody reads it; what matters is that my hands know what to type.")

Or if we had a rule that only Python developers with a minimum of 10 
years experience are allowed to use it.


[...]
> > We already have chosen -> as the return type symbol in annotations, 
> > there is no ambiguity with also using it as the return value symbol.
> 
> You're mastermind to claim it like that. I for one wasn't sure there's
> no grammar-level ambiguity.

If I'm wrong, I'm sure somebody will point that out. I'm not frightened 
of making bold claims that turn out to be wrong: that just means I have 
learned something new. (Or something old that I forgot.)

My reasoning is this:

The arrow return annotation in def functions is only legal outside of 
the parameter list, and if it is there at all, it must immediately 
follow the parameter list.

def func(params) -> ret_expression:

So any time you see a def with a parameter list, inside the parameter 
list any arrows have to be the arrow function syntax. The first arrow 
immediately following the parameter list must be the return annotation, 
and any arrows following that must be part of ret_expression which could 
of course include more arrow functions.

No matter how complicated the parameter list gets, the parser will never 
expect that return annotation arrow until the parameter list has 
completed and the closing parenthesis has been seen. Even if it is an 
unreadable mess to the human reader, to the interpreter it ought to be 
completely unambiguous: until you hit that closing parenthesis, you're 
still in the parameter list and so no arrow can be the function 
annotation arrow.

Am I right so far?

Things get a bit more complex if the arrow functions themselves can 
include annotations. Lambdas don't, so perhaps these won't either.

But if they do, I have assumed a syntax like this:

(a:T, b:T, c:T -> T) -> body

where the return type annotation is inside the bracketed argument list. 
Each of those "T"s are, naturally, arbitrary expressions, so they could 
also include arrow functions. But the parser can always tell if it is 
looking inside the parameter list, and if so, if it is a default value, 
an annotation, the return annotation, or if it has reached the end of 
the parameter list and is now in the body.

And of course, nothing in the arrow function (not the parameter 
annotations, default values, the return annotation, or the body) can 
contain a def with its `->` arrow.

So I am:

- very confident that there is no ambiguity between def function return 
  annotations and arrow functions if they don't include annotations (as
  lambdas do not);

- not so confident if they do support annotations;

- but in that case, it ought to be resolvable.

There you go: I have boldly laid my neck out on the chopping block. If I 
am wrong, I will be happy to be corrected.


> But there another problem, on humans' side. For humans, it's very
> helpful when different concept look somewhat different. 

And it is also very helpful to have similar concepts look similar.

Return a value? The critical term here is **return**.

Return type? The critical term here is also **return**.


> And it's very
> helpful to use different arrows for values vs types.

Why is it helpful? Helpful to whom?

I can see that it would be helpful to have different arrows if there 
were cases where the reader wasn't sure whether they were looking at an 
annotation or an arrow function, but I don't think that will ever be the 
case.


> > We could even allow both:
> > 
> > (values:List[float], arg=0:int -> Type) -> expression
> 
> I for one can't parse that (didn't have a morning coffee, but suspect
> there's a typo/thinko).

Yes, I swapped the order of the default value and the type annotation, 
it should read:

(values:List[float], arg:int=0 -> Type) -> expression

Sorry for the confusion.

In case anyone is still having trouble parsing that:

# lambda version
lambda values, arg=0: expression

# becomes arrow function
(values, arg=0) -> expression

# add parameter annotations
(values:List[float], arg:int=0) -> expression

# and the return type of the function body (expression)
(values:List[float], arg:int=0 -> T) -> expression


> Btw, I'm not sure about function values, but
> IMHO, type notation should always use parens for arguments, e.g. "(int)
> -> int".

What is this type notation you are talking about, and how

[Python-ideas] Re: Alternate lambda syntax

[Abdulla Al Kathiri]

def func(x: int, y: int, f: (int, int) -> int) -> int:
return f(x, y)

print(func(1, 4, (x, y) -> x + y)) #Output: 5
 
I think we can still use the same syntax for both typing.Callable and lambda. 
It would act like Callable if it comes after the “:” in annotations or after 
the “->” in function return annotation. After assignment or using it directly 
as an argument, then it acts like lambda. 

func: (str, str) -> None = (text1, text2) -> print(text1 + text2)
Same syntax, but communicates two different things. I don’t see any problem 
with this.
func: (str, str) -> None = (text1, text2) => print(text1 + text2) is not bad 
either to be honest. 

> On 14 Feb 2021, at 12:23 PM, Paul Sokolovsky  wrote:
> 
> I for one can't parse that (didn't have a morning coffee, but suspect
> there's a typo/thinko). Btw, I'm not sure about function values, but
> IMHO, type notation should always use parens for arguments, e.g. "(int)
> -> int".

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FT6E4E2B7QBGAM5PVA3D4JPFVHEP5XRJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Serhiy Storchaka]

11.02.21 13:24, J. Pic пише:
> Lambdas can be defined as such:
> 
> w = lambda: [12]
> x = lambda y: len(y)
> 
> I'd like to propose the following:
> 
> w = (): [12]
> x = (y): len(y)

This syntax is ambiguous.

if (y): len(y):

What does the first colon mean? You cannot say until you read the second
colon. It is difficult to parse for human and computer. While the
current PEG parser perhaps can handle this, it still makes parsing
slower and the code more errorprone.

Lambda is a questionable feature at all. With support of comprehensions,
local functions, the operator and functools modules there are not many
use cases for lambda expression. They are supported, well, but it is not
significant part of the language.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HX4LSMUPUGA65GQNNITM6RBPDRI34YFA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[anthony.flury via Python-ideas]

On 12/02/2021 07:32, Paul Sokolovsky wrote:

Hello,

On Fri, 12 Feb 2021 18:26:53 +1100
Chris Angelico  wrote:


On Fri, Feb 12, 2021 at 6:24 PM Paul Sokolovsky 
wrote:

... And on the 2nd thought, that won't work. The reason it works in
JS is that it doesn't have tuples. In Python, "(a, b) => (1, 2)"
means "compare a tuple for greater-or-equal".

Should be safe actually - "=>" is not a valid comparison operator.
It may not be a valid operator - but it reads as if it could be. using 
'=>' for this will decrease the readability as far as I can see.


It takes a bit of mental processing to realise this isn't a valid 
comparison, and then more processing to understand what it does mean; it 
will definitely be a source of confusion for beginners. The fact that a 
very respected member of the community got it wrong at first sight 
suggests that many will do so.


If we were going to do this - and I am still on the fence - I think we 
should avoid anything that reads like it could be confused as an operator.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3SAONT64IU4LP4ML3XARVPESJKG25CY2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Paul Sokolovsky]

Hello,

On Sun, 14 Feb 2021 18:36:14 +1100
Steven D'Aprano  wrote:

> On Thu, Feb 11, 2021 at 09:36:25PM -0800, Guido van Rossum wrote:
> 
> > Agreed. I'd prefer the JavaScript solution, since -> already has a
> > different meaning in Python return *type*. We could use -> to
> > simplify typing.Callable, and => to simplify lambda.  
> 
> Please no! That will lead to constant confusion for people who can't 
> remember which arrow operator to use. Is -> the return type symbol or 
> the return value symbol? I forsee many Stackoverflow questions
> "What's the difference between -> and => ?"
> 
> We've seen Paul mistake => for >= and he's not the only one.

Well, my mistake is based on the fact that I don't spend high-level
neurons on remembering mundane low-level things, like order of
characters if the "greater or equals" operator. Instead, low-level
hands motor function neurons get it right when I type (most of the time
;-)). It's the same as I (and many other people I'm sure) don't
remember phone numbers nowadays - why, if modern phones well remember
them themselves, transfer from one instance to another, etc.

Bottom line: after not too long practice, nobody would confuse ">=" and
"=>", as they're different on their usage context (picked up
subconsciously).

> We already have chosen -> as the return type symbol in annotations, 
> there is no ambiguity with also using it as the return value symbol.

You're mastermind to claim it like that. I for one wasn't sure there's
no grammar-level ambiguity. Perhaps now I can say: if an arrow function
appears in the type annotation position, then well, it's a type. That
should work for the parser algorithm.

But there another problem, on humans' side. For humans, it's very
helpful when different concept look somewhat different. And it's very
helpful to use different arrows for values vs types.

> We could even allow both:
> 
> (values:List[float], arg=0:int -> Type) -> expression

I for one can't parse that (didn't have a morning coffee, but suspect
there's a typo/thinko). Btw, I'm not sure about function values, but
IMHO, type notation should always use parens for arguments, e.g. "(int)
-> int".

> There are plenty of popular and influential languages that use the 
> single line arrow -> such as Maple, Haskell, Julia, CoffeeScript,
> Erlang and Groovy, to say nothing of numerous lesser known and
> obscure languages.

The question is how many of those language have first-class type
literals, and how many use the same notation for function literals and
type literals. 

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VN6KKLPVOEQ63S6FGJV2J6YOBDAM6ZIO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Steven D'Aprano]

On Thu, Feb 11, 2021 at 09:36:25PM -0800, Guido van Rossum wrote:

> Agreed. I'd prefer the JavaScript solution, since -> already has a
> different meaning in Python return *type*. We could use -> to simplify
> typing.Callable, and => to simplify lambda.

Please no! That will lead to constant confusion for people who can't 
remember which arrow operator to use. Is -> the return type symbol or 
the return value symbol? I forsee many Stackoverflow questions "What's 
the difference between -> and => ?"

We've seen Paul mistake => for >= and he's not the only one.

We already have chosen -> as the return type symbol in annotations, 
there is no ambiguity with also using it as the return value symbol. We 
could even allow both:

(values:List[float], arg=0:int -> Type) -> expression

There are plenty of popular and influential languages that use the 
single line arrow -> such as Maple, Haskell, Julia, CoffeeScript, Erlang 
and Groovy, to say nothing of numerous lesser known and obscure 
languages.



-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WBQ6FHBF4253QZR77PQOVWWYUMCBHXQI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Chris Angelico]

On Sun, Feb 14, 2021 at 9:33 AM Christopher Barker  wrote:
>
> On Fri, Feb 12, 2021 at 1:00 AM Brendan Barnwell  
> wrote:
>>
>>
>> The only thing that would be better than lambda is a less confusing
>> keyword.
>
>
> Is this really what this is all about? removing that word? I do think that 
> adding a parens around the parameters would make it a bit more clear, but it 
> currently illegal:
>
> In [18]: lambda(x, y): x + y
>   File "", line 1
> lambda(x, y): x + y
>   ^
> SyntaxError: invalid syntax
>
>>
>> So like "func x: x+2" would be better than "lambda x: x+2".
>> That probably won't happen because no one wants to add new keywords.
>

It is currently illegal, but in previous Pythons, it was legal, with
different semantics.

Python 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (lambda(x,y): x + y)(2, 3)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: () takes exactly 1 argument (2 given)
>>> (lambda(x,y): x + y)([2, 3])
5
>>>

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/W6N4M2GDXG54PJEMTA3QB55SEMFKI6R3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Christopher Barker]

On Fri, Feb 12, 2021 at 1:00 AM Brendan Barnwell 
wrote:

>
> The only thing that would be better than lambda is a less
> confusing
> keyword.


Is this really what this is all about? removing that word? I do think that
adding a parens around the parameters would make it a bit more clear, but
it currently illegal:

In [18]: lambda(x, y): x + y
  File "", line 1
lambda(x, y): x + y
  ^
SyntaxError: invalid syntax


> So like "func x: x+2" would be better than "lambda x: x+2".
> That probably won't happen because no one wants to add new keywords.
>

There seems to be a frequent objection to the word "lambda" -- personally,
I found it cryptic, but it's not hard to remember, and it IS easy to look
up. But if you don't like that word, why not "def"? Every place I've tried
to use "def" where "lambda" is legal, it's a syntax error. So we could use
the same word. Would that be less confusing?

My thought is yes it would , IF we were stating from scratch -- but this
would be a lot of churn in code and documentation for very little gain.

-Chris B





> But adding new non-keyword ways to do this isn't worth it just to save a
> few keystrokes.
>
> --
> Brendan Barnwell
> "Do not follow where the path may lead.  Go, instead, where there is no
> path, and leave a trail."
> --author unknown
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/ZGJ5WAI7YKMPSXWXOKNADRCP44SFR262/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZOLJESYPYEUAUDTP4I6NCF2PJ7STCOYV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Brendan Barnwell]

On 2021-02-12 03:18, Chris Angelico wrote:

On Fri, Feb 12, 2021 at 7:57 PM Brendan Barnwell  wrote:


On 2021-02-11 03:24, J. Pic wrote:
> Hi all,
>
> Lambdas can be defined as such:
>
> w = lambda: [12]
> x = lambda y: len(y)
>
> I'd like to propose the following:
>
> w = (): [12]
> x = (y): len(y)
>
> Or even another contraction for when there are no arguments:
>
> w =: [12]

I don't see any need for this.  It's even more cryptic than "lambda"
because at least lambda is a word you can look up.  This is just
inscrutable punctuation.  Using different punctuation like "=>" doesn't
help.


sigh. That argument again?

I just asked Google about "javascript =>" and got a bunch of perfectly
good results. Some said "arrow function", others have "=>" in the
title:
https://stackoverflow.com/questions/24900875/whats-the-meaning-of-an-arrow-formed-from-equals-greater-than-in-javas

Yes, you CAN search for punctuation. Please can this argument die?


	Okay, fine, drop that argument.  It doesn't matter.  The point is that 
we currently have a way to write anonymous functions and this proposal 
adds NO BENEFIT WHATSOEVER except that instead of typing "lambda" you 
type two parentheses, thus saving you a grand total of two keystrokes 
(you need to hit shift to get the parentheses, but not to type "lambda") 
to get something that doesn't look any less cryptic.


	Also the fact that JavaScript does something is evidence that it's 
probably not a good idea.  :-)


	I just don't understand what makes people think that "(a, b): a+b" or 
"(a, b) => a+b" or any of these other variants has any advantage at all 
over "lambda a, b: a+b".  Yes, "lambda" is cryptic and mysterious, but 
so are all these alternatives.  They don't solve any problems or allow 
anything that wasn't already possible and they would just clutter up the 
language.


--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

   --author unknown
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FUFLAMURF3T27TS3DMUF2NFN4XCYEYOJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Andy Challis]

Did you mean this Paul?

(a, b) >= (1, 2)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WO7KVCOES6COTGE4YDHKJO5Z4KNSLYLL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Paul Moore]

Fair enough. Whoever writes a PEP for this will need to do the
relevant research and present the arguments in detail. But until
someone's ready to write that PEP, we can continue discussing on the
assumption that if someone finds the async version useful, they'll
speak up.

Paul

On Fri, 12 Feb 2021 at 11:24, Abdulla Al Kathiri
 wrote:
>
>
> I am not that familiar with asyncio either. I only wrote a few utility 
> scripts that runs concurrent subprocesses mixed with some blocking functions 
> running in concurrent.ProcessPoolExecutor pool (using 
> asyncio.run_in_executor). That is all what I did with regard asyncio. Your 
> function f2 and my function f2 could be actually normal functions.
> f2 = (x, y) => asyncio.sleep(x + y). f2(3, 7) will just return a coroutine 
> that can be awaited on just fine. To be honest, i don’t even know what the 
> purpose would be with async lambda unless someone with more experience can 
> give us a use case. My guess is that it may be useful to use it as an 
> argument to another async function.
>
> Since we can write shortened normal functions (lambda), shortened generator 
> function (lambda with generator expression), people might ask why Python 
> doesn’t have shortened async function? But maybe that is not a good question 
> to begin with?
> Lambda reminds me of the half life time of isotopes. The other day, I was 
> struggling to teach this to my cousin in elementary school. I just told him 
> to imagine it like def _(args): return something. Assign it to a variable and 
> that variable replaces the underscore. He got it but he found it weird.
> Sent from my iPhone
>
> > On 12 Feb 2021, at 1:41 PM, Paul Moore  wrote:
> >
> > I'm not sure what the use cases would be for an async lambda - the key
> > is that it's not named, so the above isn't a good example as it's just
> > as easy to write
> >
> > async def f2:
> >return asyncio.sleep(x+y)
> >
> > (Excuse any errors here, I'm not that familiar with asyncio).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6VCPPUJQ6ZL2PAKIC3JMSEZE6VTDR6V5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Abdulla Al Kathiri]

I am not that familiar with asyncio either. I only wrote a few utility scripts 
that runs concurrent subprocesses mixed with some blocking functions running in 
concurrent.ProcessPoolExecutor pool (using asyncio.run_in_executor). That is 
all what I did with regard asyncio. Your function f2 and my function f2 could 
be actually normal functions.
f2 = (x, y) => asyncio.sleep(x + y). f2(3, 7) will just return a coroutine that 
can be awaited on just fine. To be honest, i don’t even know what the purpose 
would be with async lambda unless someone with more experience can give us a 
use case. My guess is that it may be useful to use it as an argument to another 
async function. 

Since we can write shortened normal functions (lambda), shortened generator 
function (lambda with generator expression), people might ask why Python 
doesn’t have shortened async function? But maybe that is not a good question to 
begin with? 
Lambda reminds me of the half life time of isotopes. The other day, I was 
struggling to teach this to my cousin in elementary school. I just told him to 
imagine it like def _(args): return something. Assign it to a variable and that 
variable replaces the underscore. He got it but he found it weird. 
Sent from my iPhone

> On 12 Feb 2021, at 1:41 PM, Paul Moore  wrote:
> 
> I'm not sure what the use cases would be for an async lambda - the key
> is that it's not named, so the above isn't a good example as it's just
> as easy to write
> 
> async def f2:
>return asyncio.sleep(x+y)
> 
> (Excuse any errors here, I'm not that familiar with asyncio).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CKZXCQE3FZCBMXYRRMWNJ7D5HRQVLVKE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Chris Angelico]

On Fri, Feb 12, 2021 at 7:57 PM Brendan Barnwell  wrote:
>
> On 2021-02-11 03:24, J. Pic wrote:
> > Hi all,
> >
> > Lambdas can be defined as such:
> >
> > w = lambda: [12]
> > x = lambda y: len(y)
> >
> > I'd like to propose the following:
> >
> > w = (): [12]
> > x = (y): len(y)
> >
> > Or even another contraction for when there are no arguments:
> >
> > w =: [12]
>
> I don't see any need for this.  It's even more cryptic than "lambda"
> because at least lambda is a word you can look up.  This is just
> inscrutable punctuation.  Using different punctuation like "=>" doesn't
> help.

sigh. That argument again?

I just asked Google about "javascript =>" and got a bunch of perfectly
good results. Some said "arrow function", others have "=>" in the
title:
https://stackoverflow.com/questions/24900875/whats-the-meaning-of-an-arrow-formed-from-equals-greater-than-in-javas

Yes, you CAN search for punctuation. Please can this argument die?

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DOP37STVDI2DXCYO3V4CNNHYHPVV4DNE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Paul Moore]

On Fri, 12 Feb 2021 at 09:26, Abdulla Al Kathiri
 wrote:
>
> I actually like the “(x, y=7) => x + y” and “async (x, y) => asyncio.sleep(x 
> + y)” for both normal and async anonymous functions respectfully.

I think it's a reasonable syntax, although it could be over-used.
That's not an issue with the syntax, though - *anything* can be
over-used :-) Experience with similar syntax in other languages
suggests this would be useful.

> I have natural aversion to the word lambda for some reason.

It does seem to cause people (including me!) a lot more problems than
one would expect, on the face of it. Maybe because it's not a common
term outside of computer science? But the endless debates over
alternative keywords have never come up with anything else that people
can agree on.

> The normal anon function has “return” implicitly, and the async anon function 
> has “return” implicitly as well. Usage:
> f1 = (x, y=7) => x + y
> f1(3) outputs 10
> f2 = async (x, y) => asyncio.sleep(x + y)
> async def main():
> coro = f2(3, 7)
> await coro
> return “waited 10 seconds”
> result = asyncio.run(main())
> print(result) # outputs “waited 10 seconds”

I'm not sure what the use cases would be for an async lambda - the key
is that it's not named, so the above isn't a good example as it's just
as easy to write

async def f2:
return asyncio.sleep(x+y)

(Excuse any errors here, I'm not that familiar with asyncio).

If there are good use cases, I think it makes sense to include async
lambda in any proposal. I'm not saying that it isn't useful, just that
it doesn't have all the history that (non-async) lambda does, so the
argument in favour of async lambda isn't as strong. Use cases are key
- adding it "just because we can" would just make the proposal more
controversial, and then the whole thing could collapse over something
secondary.

Ultimately, this would need someone to write a PEP.

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7WIDJHIDIQTPZNF2DCTF7D4C3UFC3XLY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Abdulla Al Kathiri]

I actually like the “(x, y=7) => x + y” and “async (x, y) => asyncio.sleep(x + 
y)” for both normal and async anonymous functions respectfully. I have natural 
aversion to the word lambda for some reason. The normal anon function has 
“return” implicitly, and the async anon function has “return” implicitly as 
well. Usage: 
f1 = (x, y=7) => x + y 
f1(3) outputs 10 
f2 = async (x, y) => asyncio.sleep(x + y) 
async def main():
coro = f2(3, 7) 
await coro 
return “waited 10 seconds” 
result = asyncio.run(main()) 
print(result) # outputs “waited 10 seconds”

Also, this is very close to what I brought back to discussion some time ago, 
which is typing.Callable.. instead of =>, we do -> for it. 

Correct me guys if you find any mistakes in the above. Python with those new 
proposal and Match Pattern will be so much more elegant. 

Abdulla 

Sent from my iPhone

> On 12 Feb 2021, at 12:57 PM, Brendan Barnwell  wrote:
> 
> On 2021-02-11 03:24, J. Pic wrote:
>> Hi all,
>> 
>> Lambdas can be defined as such:
>> 
>> w = lambda: [12]
>> x = lambda y: len(y)
>> 
>> I'd like to propose the following:
>> 
>> w = (): [12]
>> x = (y): len(y)
>> 
>> Or even another contraction for when there are no arguments:
>> 
>> w =: [12]
> 
>I don't see any need for this.  It's even more cryptic than "lambda" 
> because at least lambda is a word you can look up.  This is just inscrutable 
> punctuation.  Using different punctuation like "=>" doesn't help.
> 
>The only thing that would be better than lambda is a less confusing 
> keyword.  So like "func x: x+2" would be better than "lambda x: x+2". That 
> probably won't happen because no one wants to add new keywords. But adding 
> new non-keyword ways to do this isn't worth it just to save a few keystrokes.
> 
> -- 
> Brendan Barnwell
> "Do not follow where the path may lead.  Go, instead, where there is no path, 
> and leave a trail."
>   --author unknown
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/ZGJ5WAI7YKMPSXWXOKNADRCP44SFR262/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GKI3B6DQJUDWU6H72SRB4S6PJLGC5N6Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Brendan Barnwell]

On 2021-02-11 03:24, J. Pic wrote:

Hi all,

Lambdas can be defined as such:

w = lambda: [12]
x = lambda y: len(y)

I'd like to propose the following:

w = (): [12]
x = (y): len(y)

Or even another contraction for when there are no arguments:

w =: [12]


	I don't see any need for this.  It's even more cryptic than "lambda" 
because at least lambda is a word you can look up.  This is just 
inscrutable punctuation.  Using different punctuation like "=>" doesn't 
help.


	The only thing that would be better than lambda is a less confusing 
keyword.  So like "func x: x+2" would be better than "lambda x: x+2". 
That probably won't happen because no one wants to add new keywords. 
But adding new non-keyword ways to do this isn't worth it just to save a 
few keystrokes.


--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

   --author unknown
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZGJ5WAI7YKMPSXWXOKNADRCP44SFR262/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Paul Sokolovsky]

Hello,

On Fri, 12 Feb 2021 18:26:53 +1100
Chris Angelico  wrote:

> On Fri, Feb 12, 2021 at 6:24 PM Paul Sokolovsky 
> wrote:
> > ... And on the 2nd thought, that won't work. The reason it works in
> > JS is that it doesn't have tuples. In Python, "(a, b) => (1, 2)"
> > means "compare a tuple for greater-or-equal".  
> 
> Should be safe actually - "=>" is not a valid comparison operator.

LOL, indeed. Always look for small thinkos in big reasonings ;-).

Thanks!

> 
> ChrisA

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WTJ5PJACBCF6TBBUSQUVKUOHF2GCJFRE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Random832]

On Fri, Feb 12, 2021, at 02:23, Paul Sokolovsky wrote:
> > Great to hear there's no desire to stray away from JavaScript just for
> > the purpose of being different.
> 
> ... And on the 2nd thought, that won't work. The reason it works in JS
> is that it doesn't have tuples. In Python, "(a, b) => (1, 2)" means
> "compare a tuple for greater-or-equal".

Nope. greater-or-equal is >=, not =>. And Javascript may not have tuples, but 
it does have the comma operator.

> But fear not, we can steal "lambda operator" from Haskell:
> 
> \(a, b): (1, 2)

That's another option [and might be easier to parse], but I think it's less 
readable.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/H7PKBX2AAAXD4NG6EN7MIOUCP47V6UDH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Chris Angelico]

On Fri, Feb 12, 2021 at 6:24 PM Paul Sokolovsky  wrote:
> ... And on the 2nd thought, that won't work. The reason it works in JS
> is that it doesn't have tuples. In Python, "(a, b) => (1, 2)" means
> "compare a tuple for greater-or-equal".

Should be safe actually - "=>" is not a valid comparison operator.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KM3JYSXML4DDVWEXVGTAJNHTVXVQQRED/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Paul Sokolovsky]

Hello,

On Fri, 12 Feb 2021 09:55:16 +0300
Paul Sokolovsky  wrote:

> Hello,
> 
> On Thu, 11 Feb 2021 21:36:25 -0800
> Guido van Rossum  wrote:
> 
> > > but I think it'd probably be
> > > better to use similar syntax to C#, Java, and Javascript instead,
> > > and use () -> [12] or () => 12...
> > >
> > 
> > Agreed. I'd prefer the JavaScript solution, since -> already has a
> > different meaning in Python return *type*. We could use -> to
> > simplify typing.Callable, and => to simplify lambda.
> 
> Great to hear there's no desire to stray away from JavaScript just for
> the purpose of being different.

... And on the 2nd thought, that won't work. The reason it works in JS
is that it doesn't have tuples. In Python, "(a, b) => (1, 2)" means
"compare a tuple for greater-or-equal".

But fear not, we can steal "lambda operator" from Haskell:

\(a, b): (1, 2)

Or... we can do nothing, and just promote macro usage in Python,
because it's trivial to replace "lambda" with actual unicode lambda
character (or anything else for that matter, for as long as "anything
else" is not an empty string and not ambiguous with already existing
constructs): https://aroberge.github.io/ideas/docs/html/lambda.html

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FWQZHNEGZ4OVGZPQCJB3BERRKU354HXF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Paul Sokolovsky]

Hello,

On Thu, 11 Feb 2021 21:36:25 -0800
Guido van Rossum  wrote:

> > but I think it'd probably be
> > better to use similar syntax to C#, Java, and Javascript instead,
> > and use () -> [12] or () => 12...
> >  
> 
> Agreed. I'd prefer the JavaScript solution, since -> already has a
> different meaning in Python return *type*. We could use -> to simplify
> typing.Callable, and => to simplify lambda.

Great to hear there's no desire to stray away from JavaScript just for
the purpose of being different. I myself would never propose to take
any bad ideas from JS, but in some areas, it now leads.

And for wider context, it's the same idea with (informal so far)
proposal to use "const" for defining *block-local* immutable
variables, and "let" for *block-local* mutable vars. This isn't a bad
choice on its own, but also matches what JavaScript ended up to have,
and would help avoid confusion in wider programming language context.
(And yes, that use of "let" does not match its use in pure-functional
languages, but JS/Python are different beasts than pure-functional
languages).

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ETCIFVK7M64KFZIKHM3RCT4YLSJBEBM2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Paul Sokolovsky]

Hello,

On Thu, 11 Feb 2021 23:57:16 -0500
Random832  wrote:

[]

> > > I'd like to propose the following:
> > > 
> > > w = (): [12]  
> > 
> > What will be the meaning of {(): [12]} ? Hint: it will be a
> > dictionary of empty tuple mapping to a list, where do you see
> > lambda here?  
> 
> This could be solved with parentheses,

No, it can't be - parentheses are optional, and without them,
"(): [12]" and "{(): [12]}" would mean wildly different things. And any
programming language should aim to minimize and avoid such cases.

It's a similar concern which was raised for PEP642 (pattern matching
alternatives), where syntax looking related to sets, was suddenly
repurposed to mean dicts instead. Such cases are highly confusing.

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KS5YRMMVKYK5LCUQOS3IXC7DJXGUC7TV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Guido van Rossum]

On Thu, Feb 11, 2021 at 8:58 PM Random832  wrote:

> On Thu, Feb 11, 2021, at 06:48, Paul Sokolovsky wrote:
> > Hello,
> >
> > On Thu, 11 Feb 2021 12:24:55 +0100
> > "J. Pic"  wrote:
> >
> > > Hi all,
> > >
> > > Lambdas can be defined as such:
> > >
> > > w = lambda: [12]
> > > x = lambda y: len(y)
> > >
> > > I'd like to propose the following:
> > >
> > > w = (): [12]
> >
> > What will be the meaning of {(): [12]} ? Hint: it will be a dictionary
> > of empty tuple mapping to a list, where do you see lambda here?
>
> This could be solved with parentheses, but I think it'd probably be better
> to use similar syntax to C#, Java, and Javascript instead, and use () ->
> [12] or () => 12...
>

Agreed. I'd prefer the JavaScript solution, since -> already has a
different meaning in Python return *type*. We could use -> to simplify
typing.Callable, and => to simplify lambda.


> It's worth noting that all three of these are later additions to their
> respective languages, and they all have earlier, more difficult, ways of
> writing nested functions within expressions. Their designers saw the
> benefit of an easy lambda syntax, why don't we?
>

Probably we were blinded by the endless search for for multi-line lambdas.
It's not too late.


> It also may be worth looking at what it would take to allow asynchronous
> lambdas. Syntactically, while "any lambda containing await" is tempting,
> the lack of static typing means that we need a way to specify async lambdas
> that do not contain await. Javascript prefixes the argument list with async
> [i.e. "async () => ..." or "async onearg => ..."], as does C# even though
> it could in principle get away without doing so because of static typing.
>

Makes sense.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AR5B36GAMB32DXUY2RMG36ADJ5YJRMWD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Random832]

On Thu, Feb 11, 2021, at 06:48, Paul Sokolovsky wrote:
> Hello,
> 
> On Thu, 11 Feb 2021 12:24:55 +0100
> "J. Pic"  wrote:
> 
> > Hi all,
> > 
> > Lambdas can be defined as such:
> > 
> > w = lambda: [12]
> > x = lambda y: len(y)
> > 
> > I'd like to propose the following:
> > 
> > w = (): [12]
> 
> What will be the meaning of {(): [12]} ? Hint: it will be a dictionary
> of empty tuple mapping to a list, where do you see lambda here?

This could be solved with parentheses, but I think it'd probably be better to 
use similar syntax to C#, Java, and Javascript instead, and use () -> [12] or 
() => 12...

It's worth noting that all three of these are later additions to their 
respective languages, and they all have earlier, more difficult, ways of 
writing nested functions within expressions. Their designers saw the benefit of 
an easy lambda syntax, why don't we?

It also may be worth looking at what it would take to allow asynchronous 
lambdas. Syntactically, while "any lambda containing await" is tempting, the 
lack of static typing means that we need a way to specify async lambdas that do 
not contain await. Javascript prefixes the argument list with async [i.e. 
"async () => ..." or "async onearg => ..."], as does C# even though it could in 
principle get away without doing so because of static typing.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/44OSHX36GMKSUKWIHA4Q4STCSXHZTMFD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Paul Moore]

On Thu, 11 Feb 2021 at 15:09, J. Pic  wrote:
>
> I think you also need return, and double space pound space qa to pass linters:
>
> def foo(): return 1 # noqa
>
> Instead of
>
> foo = lambda: 1
>
> And this proposal:
>
> foo(): 1
>
> The benefit is just to get more out of the 80 characters when we want to 
> define a short callback.
>
> I understand this is not a life changing proposal, but was wondering if it 
> was "nice enough" to be worth proposing.

Honestly, I doubt it. If you look at the history on this list, you'll
find a lot of proposals whose main justification was "convenience" or
"it's shorter". They rarely get very far.
Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2VRIPCDKDGZVR7UZBT63XJKBOTH4IEWB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[J. Pic]

I think you also need return, and double space pound space qa to pass
linters:

def foo(): return 1 # noqa

Instead of

foo = lambda: 1

And this proposal:

foo(): 1

The benefit is just to get more out of the 80 characters when we want to
define a short callback.

I understand this is not a life changing proposal, but was wondering if it
was "nice enough" to be worth proposing.

Le jeu. 11 févr. 2021 à 15:43, Steven D'Aprano  a
écrit :

> On Thu, Feb 11, 2021 at 12:42:39PM +0100, J. Pic wrote:
>
> > foo(x): len(x)
> >
> > Would be equivalent to:
> >
> > foo = lambda x: len(x)
> >
> > Would that work?
>
> The question is not whether it would work, but whether it would be a
> good idea. What benefit does it give?
>
> Just write:
>
> def foo(x): return len(x)
>
> and no new syntax is required.
>
>
>
> --
> Steve
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/IHLLXBN5U7GMLT7GB7RWDZJYVPSWDBMV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DM5LISHEQPLPBZTDSCPSTI7DZTQYJ5WO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Steven D'Aprano]

On Thu, Feb 11, 2021 at 12:42:39PM +0100, J. Pic wrote:

> foo(x): len(x)
> 
> Would be equivalent to:
> 
> foo = lambda x: len(x)
> 
> Would that work?

The question is not whether it would work, but whether it would be a 
good idea. What benefit does it give?

Just write:

def foo(x): return len(x)

and no new syntax is required.



-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IHLLXBN5U7GMLT7GB7RWDZJYVPSWDBMV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[J. Pic]

Oh, I didn't think of it, thank you Paul.

Inspiration from JavaScript was not a good idea. Instead, would like to
propose to make the "def" keyword optional like in bash:

foo(x): len(x)

Would be equivalent to:

foo = lambda x: len(x)

Would that work?

On Thu, Feb 11, 2021 at 12:24 PM J. Pic  wrote:

> Hi all,
>
> Lambdas can be defined as such:
>
> w = lambda: [12]
> x = lambda y: len(y)
>
> I'd like to propose the following:
>
> w = (): [12]
> x = (y): len(y)
>
> Or even another contraction for when there are no arguments:
>
> w =: [12]
>
> This would also be consistent with the other proposal on anonymous
> functions for defaults:
> https://mail.python.org/pipermail/python-list/2021-February/900795.html
>
> --
> ∞
>


-- 
∞

On Thu, Feb 11, 2021 at 12:48 PM Paul Sokolovsky  wrote:

> Hello,
>
> On Thu, 11 Feb 2021 12:24:55 +0100
> "J. Pic"  wrote:
>
> > Hi all,
> >
> > Lambdas can be defined as such:
> >
> > w = lambda: [12]
> > x = lambda y: len(y)
> >
> > I'd like to propose the following:
> >
> > w = (): [12]
>
> What will be the meaning of {(): [12]} ? Hint: it will be a dictionary
> of empty tuple mapping to a list, where do you see lambda here?
>
> Generally, if you have an idea like that, please go ahead and implement
> it with one of the existing macro engines for Python. That alone should
> give yourself more insight how viable it is. Here's tutorial to get you
> started: https://github.com/aroberge/ideas#usage
>
>
>
> --
> Best regards,
>  Paul  mailto:pmis...@gmail.com
>


-- 
∞
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2AKUU5VSBIN5D76EJBJG3RSDICNEZKFF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Alternate lambda syntax

[Paul Sokolovsky]

Hello,

On Thu, 11 Feb 2021 12:24:55 +0100
"J. Pic"  wrote:

> Hi all,
> 
> Lambdas can be defined as such:
> 
> w = lambda: [12]
> x = lambda y: len(y)
> 
> I'd like to propose the following:
> 
> w = (): [12]

What will be the meaning of {(): [12]} ? Hint: it will be a dictionary
of empty tuple mapping to a list, where do you see lambda here?

Generally, if you have an idea like that, please go ahead and implement
it with one of the existing macro engines for Python. That alone should
give yourself more insight how viable it is. Here's tutorial to get you
started: https://github.com/aroberge/ideas#usage



-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ANBA6WUHSG2BCENL724PX4MIRFPR2FI3/
Code of Conduct: http://python.org/psf/codeofconduct/