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 confu
On Sat, Feb 13, 2021, at 21:57, Steven D'Aprano wrote:
> # Erlang
> multiply(X,Y) -> X * Y.
For the record, Erlang's lambda syntax is the relatively unpleasant "fun(X,Y)
-> X * Y end". Elixir is the same, except that the keyword is fn.
> Dart uses "=>"
>
> multiply(x, y) => x * y;
On Sun, Feb 14, 2021 at 12:47:30AM +0300, Paul Sokolovsky wrote:
> Hello,
>
> On Sat, 13 Feb 2021 16:25:24 -0500
> Cade Brown wrote:
>
> > In my humble opinion, arrows should be '->' instead of '=>'. It always
> > annoys me when languages use that symbol
>
> That's unlikely, as was discussed in
Thanks Rob.
You've broken a number of "rules" code code formatting there ;-)
A big one is aligning things vertically, which, as a rule, I like. but this
example does really push things out away from each other, so I'm not so
sure.
I found that the original looked like heck when I first opened it
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 tha
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, b
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
It's not my call in Python so I can't demand one way or another. I was just
saying that it makes less sense and has always been less readable for me
and most developers I've talked to, as it resembles a comparison operator.
Also, mathematically, mappings are typically written with a skinny arrow,
Hello,
On Sat, 13 Feb 2021 16:25:24 -0500
Cade Brown wrote:
> In my humble opinion, arrows should be '->' instead of '=>'. It always
> annoys me when languages use that symbol
That's unlikely, as was discussed in this thread previously:
a) JavaScript already uses "=>", and it doesn't make sens
In my humble opinion, arrows should be '->' instead of '=>'. It always
annoys me when languages use that symbol
On Sat, Feb 13, 2021, 14:52 Paul Sokolovsky wrote:
> Hello,
>
> On Sat, 13 Feb 2021 09:24:51 -0800
> Matthias Bussonnier wrote:
>
> > Works well with 0 parameters and currying, read a
Hello,
On Sat, 13 Feb 2021 09:24:51 -0800
Matthias Bussonnier wrote:
> Works well with 0 parameters and currying, read almost like a haskell
> function definition.
>
> f = () => ((b) => b)
> g = (a) => (b) => b+a
> h = (a) => (b) => (b, a)
> i = (a,b) => a
>
> print(f()(2))
> print(g(1)(2))
The solution here is not to use the same name for two different concepts in
the first place. Python doesn't have scopes associated with blocks, only
with functions, and occasionally this means you have to pick your names
carefully -- the same happens e.g. if you reuse a variable as a for-loop
contr
Works well with 0 parameters and currying, read almost like a haskell
function definition.
f = () => ((b) => b)
g = (a) => (b) => b+a
h = (a) => (b) => (b, a)
i = (a,b) => a
print(f()(2))
print(g(1)(2))
print(h(1)(2))
print(i(1, 2))
On Sat, 13 Feb 2021 at 06:35, Paul Sokolovsky wrote:
>
> He
Hello,
On Fri, 12 Feb 2021 18:26:53 +1100
Chris Angelico wrote:
> On Fri, Feb 12, 2021 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-eq
Hello,
Some time ago I posted a query regarding how the simplest possible
(while still practical to use) import hooking might look like. Since
then, I've coded up my try: https://github.com/pfalcon/python-imphook .
I'd be interested in hearing any criticism, in particular in regard to
the claims
15 matches
Mail list logo
