Arrow functions polyfill
Hello, On Fri, 12 Feb 2021 18:26:53 +1100 Chris Angelico <rosuav@gmail.com> wrote:
On Fri, Feb 12, 2021 Paul Sokolovsky <pmiscml@gmail.com> 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.
To punish myself for making such stupid mistakes, I volunteered to implement PoC of that. And by long honorable tradition, improvements to Python get implemented in Python first. So with my "imphook" thingy https://pypi.org/project/imphook/, and with the hook module at the end, following works as expected: =========== $ cat example_arrow_func.py f = (a, b) => a + b print(f(1, 2)) res = ((a, b) => a + b)(3, 4) print(res) print(list(map((x) => x * 2, [1, 2, 3, 4]))) # Confirm there's no crashing on bare tuple at the tail of file. (1, 2) $ python3 -m imphook -i mod_arrow_func -m example_arrow_func 3 7 [2, 4, 6, 8] =========== The implementation was written a bit cowboyishly in 15 mins, maybe, just maybe, you can still crash it. (For example, it clearly doesn't support newlines in arrow param list): ===== mod_arrow_func.py ====== import sys import tokenize import imphook class TokBuf: def __init__(self): self.tokens = [] def append(self, t): self.tokens.append(t) def clear(self): self.tokens.clear() def empty(self): return not self.tokens def spool(self): yield from self.tokens self.clear() def xform(token_stream): tokbuf = TokBuf() for t in token_stream: if t[1] == "(": # We're interested only in the deepest parens. if not tokbuf.empty(): yield from tokbuf.spool() tokbuf.append(t) elif t[1] == ")": nt1 = next(token_stream) nt2 = next(token_stream) if nt1[1] == "=" and nt2[1] == ">": yield (tokenize.NAME, "lambda") yield from tokbuf.tokens[1:] tokbuf.clear() yield (tokenize.OP, ":") else: yield from tokbuf.tokens tokbuf.clear() yield t yield nt1 yield nt2 elif not tokbuf.empty(): tokbuf.append(t) else: yield t def hook(modname, filename): with open(filename, "rb") as f: # Fairly speaking, tokenizing just to convert back to string form # isn't too efficient, but CPython doesn't offer us a way to parse # token stream so far, so we have no choice. source = tokenize.untokenize(xform(tokenize.tokenize(f.readline))) mod = type(imphook)(modname) exec(source, vars(mod)) return mod imphook.add_import_hook(hook, (".py",)) =========== -- Best regards, Paul mailto:pmiscml@gmail.com
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 <pmiscml@gmail.com> wrote:
Hello,
On Fri, 12 Feb 2021 18:26:53 +1100 Chris Angelico <rosuav@gmail.com> wrote:
On Fri, Feb 12, 2021 Paul Sokolovsky <pmiscml@gmail.com> 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.
To punish myself for making such stupid mistakes, I volunteered to implement PoC of that. And by long honorable tradition, improvements to Python get implemented in Python first. So with my "imphook" thingy https://pypi.org/project/imphook/, and with the hook module at the end, following works as expected:
=========== $ cat example_arrow_func.py f = (a, b) => a + b print(f(1, 2))
res = ((a, b) => a + b)(3, 4) print(res)
print(list(map((x) => x * 2, [1, 2, 3, 4])))
# Confirm there's no crashing on bare tuple at the tail of file. (1, 2)
$ python3 -m imphook -i mod_arrow_func -m example_arrow_func 3 7 [2, 4, 6, 8] ===========
The implementation was written a bit cowboyishly in 15 mins, maybe, just maybe, you can still crash it. (For example, it clearly doesn't support newlines in arrow param list):
===== mod_arrow_func.py ====== import sys import tokenize
import imphook
class TokBuf:
def __init__(self): self.tokens = []
def append(self, t): self.tokens.append(t)
def clear(self): self.tokens.clear()
def empty(self): return not self.tokens
def spool(self): yield from self.tokens self.clear()
def xform(token_stream): tokbuf = TokBuf()
for t in token_stream:
if t[1] == "(": # We're interested only in the deepest parens. if not tokbuf.empty(): yield from tokbuf.spool() tokbuf.append(t) elif t[1] == ")": nt1 = next(token_stream) nt2 = next(token_stream) if nt1[1] == "=" and nt2[1] == ">": yield (tokenize.NAME, "lambda") yield from tokbuf.tokens[1:] tokbuf.clear() yield (tokenize.OP, ":") else: yield from tokbuf.tokens tokbuf.clear() yield t yield nt1 yield nt2 elif not tokbuf.empty(): tokbuf.append(t) else: yield t
def hook(modname, filename): with open(filename, "rb") as f: # Fairly speaking, tokenizing just to convert back to string form # isn't too efficient, but CPython doesn't offer us a way to parse # token stream so far, so we have no choice. source = tokenize.untokenize(xform(tokenize.tokenize(f.readline))) mod = type(imphook)(modname) exec(source, vars(mod)) return mod
imphook.add_import_hook(hook, (".py",)) ===========
-- Best regards, Paul mailto:pmiscml@gmail.com _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/VOVHZU... Code of Conduct: http://python.org/psf/codeofconduct/
Hello, On Sat, 13 Feb 2021 09:24:51 -0800 Matthias Bussonnier <bussonniermatthias@gmail.com> 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)) print(h(1)(2)) print(i(1, 2))
Thanks for testing! Yeah, I didn't even think about recursive syntax cases, glad to know they work out of the box. Seems like writing macros for Python isn't that hard, even on the token stream level. And this comparison with Haskell - don't know if it's good or bad. Definitely feels a bit scary ;-). We'll see how this idea goes... [] -- Best regards, Paul mailto:pmiscml@gmail.com
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 <pmiscml@gmail.com> wrote:
Hello,
On Sat, 13 Feb 2021 09:24:51 -0800 Matthias Bussonnier <bussonniermatthias@gmail.com> 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)) print(h(1)(2)) print(i(1, 2))
Thanks for testing! Yeah, I didn't even think about recursive syntax cases, glad to know they work out of the box. Seems like writing macros for Python isn't that hard, even on the token stream level.
And this comparison with Haskell - don't know if it's good or bad. Definitely feels a bit scary ;-). We'll see how this idea goes...
[]
-- Best regards, Paul mailto:pmiscml@gmail.com _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/R7QVXQ... Code of Conduct: http://python.org/psf/codeofconduct/
Hello, On Sat, 13 Feb 2021 16:25:24 -0500 Cade Brown <brown.cade@gmail.com> 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 sense to be different just for the purpose of being different. That will only confuse people. b) Python already uses "->" for function return *type*. And there's idea to generalize it to *function type* in general. E.g. a function "(a, b) => a + b" can have type "(int, int) -> int". (I agree that intuitively, types would rather have "fatter" arrow, because types are "meta", but again, that doesn't correspond to the practical context we live in. So, let's look at the bright side of it - "=>" is more visible, because otherwise, arrow functions are really skinny and can be easily missed at all).
On Sat, Feb 13, 2021, 14:52 Paul Sokolovsky <pmiscml@gmail.com> wrote:
Hello,
On Sat, 13 Feb 2021 09:24:51 -0800 Matthias Bussonnier <bussonniermatthias@gmail.com> 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)) print(h(1)(2)) print(i(1, 2))
Thanks for testing! Yeah, I didn't even think about recursive syntax cases, glad to know they work out of the box. Seems like writing macros for Python isn't that hard, even on the token stream level.
And this comparison with Haskell - don't know if it's good or bad. Definitely feels a bit scary ;-). We'll see how this idea goes...
[]
-- Best regards, Paul mailto:pmiscml@gmail.com _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/R7QVXQ... Code of Conduct: http://python.org/psf/codeofconduct/
-- Best regards, Paul mailto:pmiscml@gmail.com
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, so it looks more like psuedo code. No one would use double arrow when writing it on a whiteboard. To me it seems an obvious choice and I thought I'd let it be known before it gets implemented On Sat, Feb 13, 2021, 16:47 Paul Sokolovsky <pmiscml@gmail.com> wrote:
Hello,
On Sat, 13 Feb 2021 16:25:24 -0500 Cade Brown <brown.cade@gmail.com> 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 sense to be different just for the purpose of being different. That will only confuse people. b) Python already uses "->" for function return *type*. And there's idea to generalize it to *function type* in general. E.g. a function "(a, b) => a + b" can have type "(int, int) -> int".
(I agree that intuitively, types would rather have "fatter" arrow, because types are "meta", but again, that doesn't correspond to the practical context we live in. So, let's look at the bright side of it - "=>" is more visible, because otherwise, arrow functions are really skinny and can be easily missed at all).
On Sat, Feb 13, 2021, 14:52 Paul Sokolovsky <pmiscml@gmail.com> wrote:
Hello,
On Sat, 13 Feb 2021 09:24:51 -0800 Matthias Bussonnier <bussonniermatthias@gmail.com> 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)) print(h(1)(2)) print(i(1, 2))
Thanks for testing! Yeah, I didn't even think about recursive syntax cases, glad to know they work out of the box. Seems like writing macros for Python isn't that hard, even on the token stream level.
And this comparison with Haskell - don't know if it's good or bad. Definitely feels a bit scary ;-). We'll see how this idea goes...
[]
-- Best regards, Paul mailto:pmiscml@gmail.com _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/R7QVXQ...
Code of Conduct: http://python.org/psf/codeofconduct/
-- Best regards, Paul mailto:pmiscml@gmail.com
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 <brown.cade@gmail.com> 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 sense to be different just for the purpose of being different. That will only confuse people.
It's not being different for the sake of being different. It's being different because Javascript gets it wrong, and we should get it right. *semi-wink* I wouldn't worry about being inconsistent with Javascript. We are already inconsistent with Javascript in many, many, many ways. One more is no big deal. Other popular and influential languages include: Maple, CoffeeScript, Groovy and Erlang use "->" # Maple multiply:= (a, b) -> a * b; # Coffeescript multiply = (x, y) -> x * y # Groovy def multiply = { x, y -> x * y } # Erlang multiply(X,Y) -> X * Y. Dart uses "=>" multiply(x, y) => x * y; Haskell, Ela and Elm all use "=" for named functions and "->" for anonymous functions: multiply x y = x * y \x y -> x * y Julia is similar to Haskell: multiply(a, b) = a * b (a, b) -> a * b Python uses ":" *wink* lambda a, b: a * b R uses a space: multiply = function(a,b) a*b More examples here: http://www.rosettacode.org/wiki/Function_definition The question we should be asking is not so much how popular Javascript is in absolute terms, but: - how many people coming to Python will be familiar with Javascript as opposed to R, Julia, Maple, etc, or no language at all? - given how many other things they will have to learn that is different, is one comparatively rarely used feature more that much of a burden?
b) Python already uses "->" for function return *type*. And there's idea to generalize it to *function type* in general. E.g. a function "(a, b) => a + b" can have type "(int, int) -> int".
This supports the idea of using "->" as the "return operator". In annotations, it annotates the return *type* and in function bodies it marks the return *value*. (a:int, b:int -> int) -> a*b Why have two different "return operators"? That can only lead to confusion: # Which of these are correct? (a, b) -> a*b (a, b) => a*b def func(a, b) -> Spam: pass def func(a, b) => Spam: pass # and if arrow functions allow annotations, it's even worse! (a, b -> Type) -> a*b (a, b => Type) -> a*b (a, b -> Type) => a*b (a, b => Type) => a*b Let's keep it nice and simple. We already use "->" as the "return operator", so let's use it for arrow functions too. (All of this assumes that arrow functions are justified in the first place.) -- Steve
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;
And Dart has a very C#-like (x, y) => x * y for lambdas, though a lot of material describing Dart's function syntax options seems to have some confusion about what a lambda is, with some describing the above ordinary function definition as a lambda, and some forgetting to explain it, only bothering to mention => for ordinary definitions and (x, y) { return x * y; } for lambdas.
More examples here:
That page doesn't really do well at explaining lambda expressions specifically, omitting it for some languages that definitely have them [such as Dart]. https://rosettacode.org/wiki/Higher-order_functions and https://rosettacode.org/wiki/First-class_functions both show examples of lambda syntax for some languages that it's missing from in the "Function definition" page... It's hard to sort through those from the ones that *don't* have a lambda syntax [compact or otherwise], since that's not the point of *any* of these pages though. https://en.wikipedia.org/wiki/Anonymous_function may be better. C# uses =>, same as Javascript, as does Scala, as does D - and like I said earlier, Java (and Kotlin, and as you mentioned Julia) uses essentially the same syntax but with ->. Anyway, Javascript started using this syntax in *2015*, C# did in *2007* [you may find some references that seem to say 2015 if not read closely, but these are discussing the introduction of => syntax to ordinary non-lambda function definitions]. In case that helps with some of the attitudes I'm seeing that this is in some way a Javascript thing that would somehow contaminate Python. I don't really buy that anyone wouldn't understand what passing "x=>x+1" as an argument means if they understand the concept of first-class functions generally. And if they don't, that difficulty isn't really syntactic. To add a few more examples to the language survey you seem to have started Go uses func(x, y) x * y Swift uses {x, y in return x * y} Rust uses |x, y| x * y, as does Ruby I still think arrows are the clear winner. I think they're intuitive, and I think that's *why* C# chose them and why other languages like Javascript copy them. It wouldn't be the first syntactic feature we'd have copied from C#.
- how many people coming to Python will be familiar with Javascript as opposed to R, Julia, Maple, etc, or no language at all?
I don't really understand why you're bringing up R/Julia/Maple specifically. Are you advocating for ->? I have no particular objection to that, but I don't think the difference between two slightly different looking arrows [one used in C#, Javascript, Scala, and D; the other used in Java, Kotlin, Julia, R, and Maple] is particularly difficult. I think either one is just as good as the other in terms of the meaning being intuitive when reading code.
- given how many other things they will have to learn that is different, is one comparatively rarely used feature more that much of a burden?
It's not about being the same to make it easier for people coming from a particular language. It's being the same because C# (and Javascript) gets it right, and we should get it right. *semi-wink* [and it being a "comparatively rarely used feature" is a bit of a circular argument - there's a case to be made that it's less used than it could be because the current syntax is cumbersome]
b) Python already uses "->" for function return *type*. And there's idea to generalize it to *function type* in general. E.g. a function "(a, b) => a + b" can have type "(int, int) -> int".
This supports the idea of using "->" as the "return operator".
Guido thinks it opposes it. I don't know if it makes much of a difference either way - people who wish to use annotations can use a full function definition. I don't think these should support annotations anyway, and I suspect they would mostly be used in contexts where annotations are unnecessary, such as as an argument to a function where the whole type of the function is already annotated.
On Sun, Feb 14, 2021 at 01:31:29AM -0500, Random832 wrote:
That page doesn't really do well at explaining lambda expressions specifically, omitting it for some languages that definitely have them [such as Dart].
It's a community site. I'm sure we could fix that if we wanted to and had sufficient Round Tuits.
https://en.wikipedia.org/wiki/Anonymous_function may be better.
May be or is? Either way, thanks for the link.
I don't really buy that anyone wouldn't understand what passing "x=>x+1" as an argument means if they understand the concept of first-class functions generally.
That's not the argument being made. The argument is that people will confuse -> and => and be unsure of the difference, and confuse => with >= comparison operator. I think it is disingenuous to deny that second one when this thread included a good example of a highly experienced, motivated Python programmer mixing up the two symbol. If Paul can do it, we all can.
I still think arrows are the clear winner. I think they're intuitive, and I think that's *why* C# chose them and why other languages like Javascript copy them. It wouldn't be the first syntactic feature we'd have copied from C#.
Out of curiosity, which other features are those? I don't think that the argument is specifically about arrows. (Except to the degree that we already have a way to spell anonymous functions, and it isn't clear why we need a second way just to save a handful of characters: lambda a, b, c: a+b*c (a, b, c) -> a+b*c The argument is between the arrow that can be confused with a comparison, versus the arrow that is already used for a closely related concept. In the first case, => will forever be fighting against the much stronger memory trace of >= (I think we can agree that comparisons will be more common than anonymous functions). People's muscle-memory will type >= when they want the arrow; people will wrongly read => as a comparison. And people will ask what the difference is between => and -> the arrow we already have.
- how many people coming to Python will be familiar with Javascript as opposed to R, Julia, Maple, etc, or no language at all?
I don't really understand why you're bringing up R/Julia/Maple specifically. Are you advocating for ->?
Um, yes. Wasn't it clear enough?
I have no particular objection to that, but I don't think the difference between two slightly different looking arrows [one used in C#, Javascript, Scala, and D; the other used in Java, Kotlin, Julia, R, and Maple] is particularly difficult. I think either one is just as good as the other in terms of the meaning being intuitive when reading code.
In isolation, sure. But Python already has a forward arrow -> and something that looks like a backward arrow <= but isn't.
- given how many other things they will have to learn that is different, is one comparatively rarely used feature more that much of a burden?
It's not about being the same to make it easier for people coming from a particular language. It's being the same because C# (and Javascript) gets it right, and we should get it right. *semi-wink*
Okay, let's do a shoot-out: if we were designing the syntax in isolation (no other languages exist; everyone uses Python) what are the objective advantages and disadvantages of each arrow spelling? * Clearly both -> and => look like arrows. Tie. * Both require the same number of keypresses. Tie. * Similar things should look similar. -> is already used for **return annotations** which is semantically related to **return values** so the use of -> for both concepts strengthens the association of the arrow symbol with returning stuff. * Things which look confusingly similar cause confusion. => looks confusingly similar to -> which will lead to people mixing up the two arrows and asking "what's the difference between ...?" * Things which are dissimilar should look dissimilar. => is very different from >= and <= but they look similar. Every advantage of => is equally shared with -> but => has two disadvantages, and no advantages, compared to ->. So if we're tallying pros - cons for each symbol, I make that: => 2 pros - 2 cons = 0 -> 3 pros - 0 cons = 3 I think this is a slam dunk. If you disagree, can you give some objective pluses for the => symbol that doesn't rely on familiarity with other languages? -- Steve
On Mon, Feb 15, 2021 at 5:28 PM Steven D'Aprano <steve@pearwood.info> wrote:
In the first case, => will forever be fighting against the much stronger memory trace of >= (I think we can agree that comparisons will be more common than anonymous functions). People's muscle-memory will type >= when they want the arrow; people will wrongly read => as a comparison.
I've worked a lot with JS's arrow functions, and I've taught them to a good number of students, and this is basically a non-issue. In JS, the need for arrow functions is a lot stronger, as they actually have different semantics to "function functions" (for want of a better word). In Python, the need isn't as great, but there would be some minor value in this syntax. Overall I'm +0.1 on either => or ->, and have absolutely no push either way which one is chosen. ChrisA
Hello, On Sun, 14 Feb 2021 13:57:14 +1100 Steven D'Aprano <steve@pearwood.info> wrote:
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 <brown.cade@gmail.com> 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 sense to be different just for the purpose of being different. That will only confuse people.
It's not being different for the sake of being different. It's being different because Javascript gets it wrong, and we should get it right.
*semi-wink*
I wouldn't worry about being inconsistent with Javascript. We are already inconsistent with Javascript in many, many, many ways. One more is no big deal.
There're 2 things about that from an experienced JavaScript-hater (but a pragmatic guy otherwise): 1. We aren't talking about all of JavaScript, but a recent features added to JS. 2. JS has real money being poured into it, and no longer designed on two-week vacations, when nobody looks. On the JS committees/proposal author lists are guys who have publications in serious programming language design matters and "grown up" languages, like proverbial Haskell. And they peer-review each other. So, with due understanding of the baseline https://en.wikipedia.org/wiki/Design_by_committee process, some recent features in JS are well-designed.
Other popular and influential languages include:
Please make sure this list ends up in the PEP, because we really, really should explicitly learn/compare Python with other languages (that's what actual users (or leavers) of the language do). []
The question we should be asking is not so much how popular Javascript is in absolute terms, but:
- how many people coming to Python will be familiar with Javascript as opposed to R, Julia, Maple, etc, or no language at all?
I think that the answer is "very many". JS is both companion and competitor of Python. Companion, as very many people work on webapps (best practice in application-level (not sytem-level) development nowadays), and constantly switch between backend code in Python and frontend (in-browser) code in JS. Competitor in everything else (and making Python purposely different, which oftentimes translates to "worse" doesn't help here).
- given how many other things they will have to learn that is different, is one comparatively rarely used feature more that much of a burden?
Again, we're talking about specific recent things (one now, but we'll be returning to that). And arrow functions are now very popular in JS, so someone hearing that Python added will immediately proceed to check, and on discovery that they look different, they'd conclude it was done on purpose, to confuse people.
b) Python already uses "->" for function return *type*. And there's idea to generalize it to *function type* in general. E.g. a function "(a, b) => a + b" can have type "(int, int) -> int".
This supports the idea of using "->" as the "return operator". In annotations, it annotates the return *type* and in function bodies it marks the return *value*.
(a:int, b:int -> int) -> a*b
Why have two different "return operators"? That can only lead to confusion:
Because even calling them "return operators" is "abuse of notation". And because things "returned" are wildly different. If first case, it's *value*, in second - it's *type*. These concepts are from different levels (types are at meta-level of values), and mean very different things.
# Which of these are correct?
(a, b) -> a*b
This is a function type, where arbitrary types are accepted, and the function returns product type of them, i.e. a tuple. We unlikely would use that notation, rather literal tuple notation, so it would be: (a, b) -> (a, b) (But that's an idea how to "free up" tuple syntax in new-style annotations for something else. But I don't think it would fly).
(a, b) => a*b
This is a function which returns things multiplied.
def func(a, b) -> Spam: pass
Normal familiar by now function annotation.
def func(a, b) => Spam: pass
This is syntax error.
# and if arrow functions allow annotations, it's even worse!
It's better, because it allows to distinguish value-level from type meta-level.
(a, b -> Type) -> a*b (a, b => Type) -> a*b (a, b -> Type) => a*b (a, b => Type) => a*b
In first approximation, these all are syntax errors. Practically, I guess for arrow functions, we'll need to allow single args without parens, e.g. "a => a + 1", then some of the above will make sense. (But as I mentioned, IMHO exception shouldn't apply for types, or we go to the land of functional-egghead confusion).
Let's keep it nice and simple. We already use "->" as the "return operator", so let's use it for arrow functions too.
(All of this assumes that arrow functions are justified in the first place.)
+1 on that predicate. I myself not sure ;-). -- Best regards, Paul mailto:pmiscml@gmail.com
On Sun, Feb 14, 2021 at 11:54:21AM +0300, Paul Sokolovsky wrote:
b) Python already uses "->" for function return *type*. And there's idea to generalize it to *function type* in general. E.g. a function "(a, b) => a + b" can have type "(int, int) -> int".
This supports the idea of using "->" as the "return operator". In annotations, it annotates the return *type* and in function bodies it marks the return *value*.
(a:int, b:int -> int) -> a*b
Why have two different "return operators"? That can only lead to confusion:
Because even calling them "return operators" is "abuse of notation".
You're right, thank you for the correction. They aren't operators, although people will call them that, just as the speak of name.attr as "the dot operator". Let me rephrase it: Why have two different return **symbols** when they are so closely related?
And because things "returned" are wildly different. If first case, it's *value*, in second - it's *type*.
This is a small and unimportant difference, and with good type inference the second is redundant. The critical feature here is not what is returned, but the fact that it marks a return. The first is a symbol that marks the value returned. The second is an annotation symbol that marks the type of the value returned. There is no syntactic or semantic confusion between the two, the difference is obvious from context to both the human reader and the interpreter. Having two different symbols for this would be like having two ever so slightly different keywords for for loops and comprehensions: for x in sequence: block [expression por x in sequence] For loops are widely different from comprehensions! The first is a block statement, the second is an expression, these are completely different things and should have completely different keywords to avoid confusion! No. This would *cause* confusion when people fail to remember the difference between for and por (Spanish, for those who wonder), and there would be a continual stream of people asking "what's the difference between for and por?" And so there will be confusion when people fail to remember the difference between -> and => and have to ask what the difference is. And people will confuse => with >= as you already did. Being different just for the sake of being different is a bad idea, but being different because -> is a better fit to the existing language is an excellent idea. We should not choose the more confusing, error-prone solution out of fear of being different. Python is already different from Javascript in every regard: - the basic execution model is different; - the object model is different; - the numeric model is different; -the truthy/falsey model is different; - the syntax is different; - the list of keywords is different; - the standard library is different; - the list of operators is different; - even basic equality is different; - the culture of the community is different. "Javascript spells it this way" might be a compelling argument if the choice between the two symbols was neutral, but it isn't: * the double line arrow => is confusable with greater-than-or-equal; * the single line arrow -> is already used in Python for a related, but unambiguously distinct, meaning. -- Steve
On Sun, Feb 14, 2021 at 8:42 PM Steven D'Aprano <steve@pearwood.info> wrote:
We should not choose the more confusing, error-prone solution out of fear of being different. Python is already different from Javascript in every regard:
Is it really?
- the basic execution model is different; Don't know what you mean here, but I thought they were the same.
- the object model is different; Same object model.
- the numeric model is different; Python has more data types, but that's not as fundamental a difference as you might think
-the truthy/falsey model is different; There are different rules about WHAT is truthy/falsy, but, again, the differences aren't fundamental
- the syntax is different; - the list of keywords is different; - the standard library is different; - the list of operators is different; Well, of course. If these four were the same, they'd be the same language. These four differ between Py2 and Py3 too.
- even basic equality is different; Yes, although that's more historic than anything else - most people use "===" which has mostly the same semantics as Python's equality
- the culture of the community is different. TBH neither community has a single culture.
https://tvtropes.org/pmwiki/pmwiki.php/Main/NotSoDifferent Python and JavaScript can learn a LOT from each other, because the languages are actually pretty similar. Yes, of course there are differences, but there are similarities too. Python has fewer similarities with C than with JS, but still enough to learn from.
"Javascript spells it this way" might be a compelling argument if the choice between the two symbols was neutral, but it isn't:
* the double line arrow => is confusable with greater-than-or-equal;
* the single line arrow -> is already used in Python for a related, but unambiguously distinct, meaning.
I think this is the key to the whole argument. *IS it* unambiguously distinct? There are enough other languages using "=>" AND enough other languages using "->" that using either in Python will be following prior art. The only real difference is that Python has one of them in use, and the other not in use. I personally don't much care whether it's spelled "=>" or "->", but I'd say the best way to judge the potential ambiguity is to try it with "->" and see how it looks. ChrisA
On Mon, Feb 15, 2021 at 02:12:03AM +1100, Chris Angelico wrote:
On Sun, Feb 14, 2021 at 8:42 PM Steven D'Aprano <steve@pearwood.info> wrote:
We should not choose the more confusing, error-prone solution out of fear of being different. Python is already different from Javascript in every regard:
Is it really?
Well, they're both Turing Complete, so I guess not different in *every* regard :-) By the way, I'm not judging the differences.
- the basic execution model is different; Don't know what you mean here, but I thought they were the same.
Python has a purely dynamic execution model; Javascript has a hybrid two-pass model that combines elements of static and dynamic execution, and which allows code like this to run: print(f(3)); function f(a) { return a*2; } (not in an interactive REPL of course). Although both Python and Javascript have dynamic typing, Python's type model is stronger (i.e. stricter) than Javascript's. 1 + '2' # an error in Python, 12 in Javascript. In Python, every thing is an object; in Javascript, some things are objects, and some things are primitive values.
- the object model is different; Same object model.
Absolutely not. Javascript is based on the prototype object model, and Python is based on the class object model. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_...
- the numeric model is different; Python has more data types, but that's not as fundamental a difference as you might think
Python has a numeric tower; Javascript has a single floating point type. It's hard to build a tower with a single brick :-)
-the truthy/falsey model is different; There are different rules about WHAT is truthy/falsy, but, again, the differences aren't fundamental
The differences are precisely my point.
- the syntax is different; - the list of keywords is different; - the standard library is different; - the list of operators is different; Well, of course. If these four were the same, they'd be the same language. These four differ between Py2 and Py3 too.
Yes, the fact that they are different languages is my point.
- even basic equality is different; Yes, although that's more historic than anything else - most people use "===" which has mostly the same semantics as Python's equality
"Mostly the same", apart from being completely different :-( Javascript's === tests for "same type and equal" for primitive values, and is equivalent to Python's `is` for objects. It cannot be overloaded.
- the culture of the community is different. TBH neither community has a single culture.
Of course neither group of people is a monoculture of identical clones. That would be the Haskell community *wink* But in general, the JS/Node.js community embraces practices which are rejected by the Python community, such as the use of micro-packages. Remember left-pad? This four-line package got nearly fifty million downloads last week: https://www.npmjs.com/package/isarray That's about 78 times per second. If I published that on PyPI, I would be amazed if I got 78 downloads in a year. -- Steve
Okay, here’s my dilemma. It looks like this thread wants to devise a new syntax for lambda, using e.g. (x, y) -> x+y, or the same with =>. That’s great, but doesn’t open new vistas. OTOH, for people using type annotations, a much more pressing issue is an alternative for typing.Callable that is more readable, and supports extra features that Callable doesn’t, like keyword args, varargs, and pos-only. If you can do both with the same arrow, great, but if the arrows must differ (for some technical reason, e.g. types in cast()), I want -> for Callable, and you can have => for lambda. —Guido On Mon, Feb 15, 2021 at 02:51 Steven D'Aprano <steve@pearwood.info> wrote:
On Mon, Feb 15, 2021 at 02:12:03AM +1100, Chris Angelico wrote:
On Sun, Feb 14, 2021 at 8:42 PM Steven D'Aprano <steve@pearwood.info> wrote:
We should not choose the more confusing, error-prone solution out of fear of being different. Python is already different from Javascript in every regard:
Is it really?
Well, they're both Turing Complete, so I guess not different in *every* regard :-)
By the way, I'm not judging the differences.
- the basic execution model is different; Don't know what you mean here, but I thought they were the same.
Python has a purely dynamic execution model; Javascript has a hybrid two-pass model that combines elements of static and dynamic execution, and which allows code like this to run:
print(f(3));
function f(a) { return a*2; }
(not in an interactive REPL of course).
Although both Python and Javascript have dynamic typing, Python's type model is stronger (i.e. stricter) than Javascript's.
1 + '2' # an error in Python, 12 in Javascript.
In Python, every thing is an object; in Javascript, some things are objects, and some things are primitive values.
- the object model is different; Same object model.
Absolutely not. Javascript is based on the prototype object model, and Python is based on the class object model.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_...
- the numeric model is different; Python has more data types, but that's not as fundamental a difference as you might think
Python has a numeric tower; Javascript has a single floating point type. It's hard to build a tower with a single brick :-)
-the truthy/falsey model is different; There are different rules about WHAT is truthy/falsy, but, again, the differences aren't fundamental
The differences are precisely my point.
- the syntax is different; - the list of keywords is different; - the standard library is different; - the list of operators is different; Well, of course. If these four were the same, they'd be the same language. These four differ between Py2 and Py3 too.
Yes, the fact that they are different languages is my point.
- even basic equality is different; Yes, although that's more historic than anything else - most people use "===" which has mostly the same semantics as Python's equality
"Mostly the same", apart from being completely different :-(
Javascript's === tests for "same type and equal" for primitive values, and is equivalent to Python's `is` for objects. It cannot be overloaded.
- the culture of the community is different. TBH neither community has a single culture.
Of course neither group of people is a monoculture of identical clones. That would be the Haskell community *wink*
But in general, the JS/Node.js community embraces practices which are rejected by the Python community, such as the use of micro-packages. Remember left-pad?
This four-line package got nearly fifty million downloads last week:
https://www.npmjs.com/package/isarray
That's about 78 times per second.
If I published that on PyPI, I would be amazed if I got 78 downloads in a year.
-- Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/7RDIPZ... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)
On Mon, Feb 15, 2021 at 4:19 PM Guido van Rossum <guido@python.org> wrote:
Okay, here’s my dilemma. It looks like this thread wants to devise a new syntax for lambda, using e.g. (x, y) -> x+y, or the same with =>. That’s great, but doesn’t open new vistas. OTOH, for people using type annotations, a much more pressing issue is an alternative for typing.Callable that is more readable, and supports extra features that Callable doesn’t, like keyword args, varargs, and pos-only.
FWIW, I *do not* want an alternate spelling for lambda. If your time machine were still working, and you could go back to 1991 to change the spelling, yes I might like that. For that matter, if someone had a good spelling for multi-line lambdas, I might like that. Or *maybe* some other difference in behavior, but nothing comes immediately to mind. But allowing a few cryptic punctuation symbols to express an anonymous function while still retaining "the name of a cryptic greek letter" to do exactly the same thing seems like a strong non-goal. That said, if I had to look at one, I'd like '->' much better than '=>'.
On Mon, Feb 15, 2021, 11:34 AM David Mertz <mertz@gnosis.cx> wrote:
On Mon, Feb 15, 2021 at 4:19 PM Guido van Rossum <guido@python.org> wrote:
Okay, here’s my dilemma. It looks like this thread wants to devise a new syntax for lambda, using e.g. (x, y) -> x+y, or the same with =>. That’s great, but doesn’t open new vistas. OTOH, for people using type annotations, a much more pressing issue is an alternative for typing.Callable that is more readable, and supports extra features that Callable doesn’t, like keyword args, varargs, and pos-only.
FWIW, I *do not* want an alternate spelling for lambda.
If your time machine were still working, and you could go back to 1991 to change the spelling, yes I might like that. For that matter, if someone had a good spelling for multi-line lambdas, I might like that. Or *maybe* some other difference in behavior, but nothing comes immediately to mind.
But allowing a few cryptic punctuation symbols to express an anonymous function while still retaining "the name of a cryptic greek letter" to do exactly the same thing seems like a strong non-goal.
That said, if I had to look at one, I'd like '->' much better than '=>'.
I also don't see this as a very worthwhile goal. But if we could expand the proposal to allow both anonymous and named functions, that would seem like a fantastic idea to me. Anonymous function syntax: (x,y)->x+y Named function syntax: f(x,y)->x+y But since Guido wants to save the right shaft operator for type hinting, and named functions do need a way to write type hints, maybe the best thing to do is use an equal sign shaft for the function definition and the right shaft for the type hint: f(x,y)=>x,y->str
f('a','b') 'ab' f(1,2) # type hint error
Rick.
On Mon, Feb 15, 2021 at 12:02 PM Ricky Teachey <ricky@teachey.org> wrote:
On Mon, Feb 15, 2021, 11:34 AM David Mertz <mertz@gnosis.cx> wrote:
On Mon, Feb 15, 2021 at 4:19 PM Guido van Rossum <guido@python.org> wrote:
Okay, here’s my dilemma. It looks like this thread wants to devise a new syntax for lambda, using e.g. (x, y) -> x+y, or the same with =>. That’s great, but doesn’t open new vistas. OTOH, for people using type annotations, a much more pressing issue is an alternative for typing.Callable that is more readable, and supports extra features that Callable doesn’t, like keyword args, varargs, and pos-only.
FWIW, I *do not* want an alternate spelling for lambda.
If your time machine were still working, and you could go back to 1991 to change the spelling, yes I might like that. For that matter, if someone had a good spelling for multi-line lambdas, I might like that. Or *maybe* some other difference in behavior, but nothing comes immediately to mind.
But allowing a few cryptic punctuation symbols to express an anonymous function while still retaining "the name of a cryptic greek letter" to do exactly the same thing seems like a strong non-goal.
That said, if I had to look at one, I'd like '->' much better than '=>'.
I also don't see this as a very worthwhile goal.
But if we could expand the proposal to allow both anonymous and named functions, that would seem like a fantastic idea to me.
Anonymous function syntax:
(x,y)->x+y
Named function syntax:
f(x,y)->x+y
But since Guido wants to save the right shaft operator for type hinting, and named functions do need a way to write type hints, maybe the best thing to do is use an equal sign shaft for the function definition and the right shaft for the type hint:
f(x,y)=>x,y->str
f('a','b') 'ab' f(1,2) # type hint error
Rick.
Sorry I was typing that last one on my phone and typed a mistake. Should have been a plus sign in the expression and not a comma: f(x,y)=>x+y->str
f('a','b') 'ab' f(1,2) # type hint error
--- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
On Mon, Feb 15, 2021 at 12:29 PM Ricky Teachey <ricky@teachey.org> wrote:
f(x,y)=>x+y->str
I can't -1 this enough. How do I read this? Imagine you have never seen this discussion and you come across this code in the wild. You are familiar with type hints, including return type annotations, but aren't familiar with this syntax. From that perspective, what does this code mean? 1) Define a function that returns x plus an instance of typing.Callable[[y], str] (assuming that the discussed Callable shorthand has been adopted) 2) Define a function that returns the sum of x and y, but with the return type annotated as a str 3) Call the function f with arguments x and y, and attempt to compare the return value to... something (except the user made a typo and you'll actually get a syntax error) 4) Absolutely nothing and it's just random electronic scribbling by the author that won't compile and they forgot to comment out (yes, that's always an option) Frankly, it's not obvious to me. Some mental gymnastics might eventually land me at 2), but now my head hurts. My preferred spelling of the above (with the addition of sample parameter type hints) would be: f(x: int, y: int) -> str: x, y (No, the type hints don't make sense. They're just an example of syntax.) Benefits over your proposal: 1) No ugly => that looks like a greater-or-equal operator if you haven't had your morning coffee 2) Looks a lot more like existing syntax (the smaller the delta between old and new, the easier it is to learn and adopt the new). In fact, it basically IS existing syntax, except for the lack of a "def" in front and an explicit "return" keyword (seriously, insert those two keywords and it compiles already). 3) Works just as well with anonymous functions: `(x: int, y: int) -> str: x, y` is clear and and easy to deduce the meaning of to anyone familiar with basic Python syntax 4) Much more Pythonic than the => syntax -- because it already looks like Python code. Even with that spelling, I'm -0.5 on the named function version (for the reasons described by Guido), and only +0.5 on the anonymous version (because I'm not convinced that it's needed).
On Mon, Feb 15, 2021 at 12:30 PM Guido van Rossum <guido@python.org> wrote:
On Mon, Feb 15, 2021 at 9:02 AM Ricky Teachey <ricky@teachey.org> wrote:
[...] But if we could expand the proposal to allow both anonymous and named functions, that would seem like a fantastic idea to me.
Anonymous function syntax:
(x,y)->x+y
Named function syntax:
f(x,y)->x+y
Proposals like this always baffle me. Python already has both anonymous and named functions. They are spelled with 'lambda' and 'def', respectively. What good would it do us to create an alternate spelling for 'def'?
Thanks for responding. I don't want to derail this discussion especially since I've brought it up in the last several months and didn't get anywhere on it. To answer the question though: I think it would really open up python to a whole group of people are find the idea of "programming" too intimidating but could benefit from it immensely. This could happen if writing a function was made more similar to what they already KNOW how to write (handwritten math). A common thing I hear from colleagues is "I'm not a developer, I'm not a programmer, I'm an engineer", and seeing this just intimidates people: lambda x,y: (x**2+y**2)**0.5 def hypotenuse(x,y): (x**2+y**2)**0.5 Allowing short one-line functions to be spelled something like this would be more friendly because it looks so familiar, nearly identical to a handwritten mathematical equation: hypotenuse(x,y) => (x**2+y**2)**0.5 Anyway I've offered up this desire to this list before and for the most part people haven't been very receptive, so I won't belabor it. But I thought I'd bring it up again in this context since this: f(x,y) => x+y ...and this: (x,y) => x+y ...would be SO CLOSE to each other. You could also write this, I suppose: hypotenuse = (x,y) => (x**2+y**2)**0.5 But that isn't any better for the casually programming engineer than lambda or def, to be honest. On Mon, Feb 15, 2021 at 12:40 PM Jonathan Goble <jcgoble3@gmail.com> wrote:
On Mon, Feb 15, 2021 at 12:29 PM Ricky Teachey <ricky@teachey.org> wrote:
f(x,y)=>x+y->str
I can't -1 this enough. How do I read this?
Imagine you have never seen this discussion and you come across this code in the wild. You are familiar with type hints, including return type annotations, but aren't familiar with this syntax. From that perspective, what does this code mean?
...
My preferred spelling of the above (with the addition of sample parameter type hints) would be:
f(x: int, y: int) -> str: x, y
...
Even with that spelling, I'm -0.5 on the named function version (for the reasons described by Guido), and only +0.5 on the anonymous version (because I'm not convinced that it's needed).
I see your point and I would be fine with that spelling. With no type hints it would look like: hypotenuse(x,y): (x**2+y**2)**0.5 That would seem fine to me. Anyway as I said above, I know this is an uphill battle. I'll leave it alone unless other people come out liking the anonymous and non-anonymous function syntax idea. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
On 15 Feb 2021, at 9:48 PM, Ricky Teachey <ricky@teachey.org> wrote:
hypotenuse(x,y): (x**2+y**2)**0.5
Can I use a named function (proposed here) as an argument to a function? e.g., def example(func, x, y): return func(x, y) example(hypotenuse(x,y): (x**2+y**2)**0.5, 3, 4) Or should it be an anonymous function like this? example((x,y): (x**2+y**2)**0.5, 3, 4) Maybe with named function, it would be something like this? hypotenuse(x,y): (x**2+y**2)**0.5 example(hypotenuse, 3, 4)
On Mon, Feb 15, 2021 at 12:55 PM David Mertz <mertz@gnosis.cx> wrote:
On Mon, Feb 15, 2021, 12:26 PM Ricky Teachey
f(x,y)=>x,y->str
I read this as "my cat walked across my keyboard, and I'm very proud she wants to be a programmer."
Our cat died last fall so if that's what happened, I should be pretty spooked right now! --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
Hello, On Mon, 15 Feb 2021 13:00:50 -0500 Ricky Teachey <ricky@teachey.org> wrote:
On Mon, Feb 15, 2021 at 12:55 PM David Mertz <mertz@gnosis.cx> wrote:
On Mon, Feb 15, 2021, 12:26 PM Ricky Teachey
f(x,y)=>x,y->str
I read this as "my cat walked across my keyboard, and I'm very proud she wants to be a programmer."
Our cat died last fall so if that's what happened, I should be pretty spooked right now!
Apparently, desire to be a *functional* programmer and write functions in short notation prevails.
--- Ricky.
-- Best regards, Paul mailto:pmiscml@gmail.com
On Mon, Feb 15, 2021 at 9:02 AM Ricky Teachey <ricky@teachey.org> wrote:
[...] But if we could expand the proposal to allow both anonymous and named functions, that would seem like a fantastic idea to me.
Anonymous function syntax:
(x,y)->x+y
Named function syntax:
f(x,y)->x+y
Proposals like this always baffle me. Python already has both anonymous and named functions. They are spelled with 'lambda' and 'def', respectively. What good would it do us to create an alternate spelling for 'def'? I know that in JavaScript there are different ways to define functions ('function' and '=>'), and they have subtly different semantics. (For example, regarding 'this'. Such an incredible mess!) We don't need different semantics in Python. I can sympathize with trying to get a replacement for lambda, because many other languages have jumped on the arrow bandwagon, and few Python first-time programmers have enough of a CS background to recognize the significance of the word lambda. But named functions? Why??
But since Guido wants to save the right shaft operator for type hinting, and named functions do need a way to write type hints, maybe the best thing to do is use an equal sign shaft for the function definition and the right shaft for the type hint:
f(x,y)=>x,y->str
f('a','b') 'ab' f(1,2) # type hint error
Another thing. Type hints are not interpreted at runtime, and I don't expect this to change in the near to middle future. Plus, that syntax really has nothing to recommend it. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
On 16/02/21 6:29 am, Guido van Rossum wrote:
I can sympathize with trying to get a replacement for lambda, because many other languages have jumped on the arrow bandwagon, and few Python first-time programmers have enough of a CS background to recognize the significance of the word lambda.
I think there's also just a desire for brevity. In the situations where it's appropriate to use a lambda, you want something very compact, and "lambda" is a rather long and unwieldy thing to have stuck in there. Another thing that comes to mind is that the way Python uses "lambda" is somewhat arbitrary. In Lisp, the first programming language where it was used, it's the *fundamental* way of creating a function. All the other function-defining constructs are macros that expand into something containing a lambda. But Python uses it *only* for in-line anonymous functions, so it feels sort of tacked on. I'm not arguing for or against anything here, just exploring possible reasons why the idea of lambda-replacement comes up so often. -- Greg
On 15.02.21 22:42, Greg Ewing wrote:
On 16/02/21 6:29 am, Guido van Rossum wrote:
I can sympathize with trying to get a replacement for lambda, because many other languages have jumped on the arrow bandwagon, and few Python first-time programmers have enough of a CS background to recognize the significance of the word lambda.
I think there's also just a desire for brevity. In the situations where it's appropriate to use a lambda, you want something very compact, and "lambda" is a rather long and unwieldy thing to have stuck in there.
I hope I am not saying something outrageous now but we used
obj = lambda: 0
to define an anomyous object without the need to define a class first (speaking of brevity). "Why?", you may ask. The reason is that:
obj = object()
does not create an instance of obj that can be used to add some attributes later on. So, my conclusion is, if "()->0" replaces "lambda:0", this very important use-case should still be possible. :-P Or make "object()" mutable. :-D
[...] I'm not arguing for or against anything here, just exploring possible reasons why the idea of lambda-replacement comes up so often.
I agree the most obvious reason would be that it looks different than in other languages (same for me when I discovered it like 10 years ago). But as Guido said it's fixed already and I don't think it adds much to the language IMHO. Maybe, I'm too old to see the benefit of changing it. I like named functions because, well, they have a name attached to them and that makes bug-fixing, debugging, logging, etc. much easier. Best, Sven
On Tue, Feb 16, 2021 at 04:43:11PM +0100, Sven R. Kunze wrote:
obj = lambda: 0
to define an anomyous object without the need to define a class first (speaking of brevity).
"Why?", you may ask. The reason is that:
obj = object()
does not create an instance of obj that can be used to add some attributes later on.
>>> from types import SimpleNamespace >>> obj = SimpleNamespace() >>> obj.spam = 1 >>> obj namespace(spam=1) Gives you a nice repr so when you are debugging you can actually see what the object is. -- Steve
On 16.02.21 17:26, Steven D'Aprano wrote:
>>> from types import SimpleNamespace >>> obj = SimpleNamespace() >>> obj.spam = 1 >>> obj namespace(spam=1)
Gives you a nice repr so when you are debugging you can actually see what the object is.
I see that's Python 3 (vs. Python2.7 - yeah I know, legacy code). But thanks for the remark! :-) Still think that "object()" should be writable since this seems like an arbitrary restriction (+SimpleNamespace is no builtin and at least I would use object() for fast PoCs or dirty hackery). But I guess there's been discussion around this already. Best, Sven
On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze <srkunze@mail.de> wrote:
Still think that "object()" should be writable since this seems like an arbitrary restriction (+SimpleNamespace is no builtin and at least I would use object() for fast PoCs or dirty hackery). But I guess there's been discussion around this already.
It can't, because subclasses of object would then ALSO be writable, and that would break a lot of things. Also, a lot of use-cases for object() just need sentinels, with no attributes, so this would cost them a lot of efficiency. Using SimpleNamespace is the best way to do this, and maybe there's a good argument for making it a builtin (or at least giving it a shorter name), but changing object would be problematic. ChrisA
On Mon, Feb 15, 2021 at 09:29:45AM -0800, Guido van Rossum wrote:
Proposals like this always baffle me. Python already has both anonymous and named functions. They are spelled with 'lambda' and 'def', respectively. What good would it do us to create an alternate spelling for 'def'? [...]
I think that the desire probably comes from thinking of short mathematical functions where the body is a simple expression, like in maths: def f(x): return 3*(x**2) - 2*x + 4 is kinda clunky and not very maths-like compared to: f(x) -> 3*(x**2) - 2*x + 4 which is suggestive of function notation: f : ℝ -> ℝ, f(x) = 3*(x**2) - 2*x + 4 If you've used modern Computer Algebra System calculators, they often have similar notation: # Texas Instruments Nspire 3⋅x² − 2⋅x + 4 -> y (except they have a proper arrow too, not just ASCII hyphen greater than). So there is definitely some aesthetic advantage to the arrow if you're used to maths notation, and if Python had it, I'd use it. But it doesn't scale up to multi-statement functions, and doesn't bring any new functionality into the language, so I'm not convinced that its worth adding as a mere synonym for def or lambda or both. -- Steve
Hi, My personal opinion is that arrows or even fat arrows would be a nice addition to the Python language for anonymous functions. I cringe a bit every time I have to write "lambda x: ..." (and even more for parameter-less "lambda: ..."). I have a background in math so I find arrow notation very natural. I have studied a bit lambda calculus, so I can relate to a notation inspired by it too, but I believe: 1) That for it to be elegant, it should be more concise e.g. "ƛx: .." not "lambda x: ..." (but Python is not APL and I don't believe we are ready to introduce non-ascii unicode notations in the language). 2) More importantly, I believe most people are more familiar with the arrow notation than the lambda notation (lambda calculus is, AFAIK, only taught in advanced logic or CS courses at the University). S. On Tue, Feb 23, 2021 at 10:26 AM Steven D'Aprano <steve@pearwood.info> wrote:
On Mon, Feb 15, 2021 at 09:29:45AM -0800, Guido van Rossum wrote:
Proposals like this always baffle me. Python already has both anonymous and named functions. They are spelled with 'lambda' and 'def', respectively. What good would it do us to create an alternate spelling for 'def'? [...]
I think that the desire probably comes from thinking of short mathematical functions where the body is a simple expression, like in maths:
def f(x): return 3*(x**2) - 2*x + 4
is kinda clunky and not very maths-like compared to:
f(x) -> 3*(x**2) - 2*x + 4
which is suggestive of function notation:
f : ℝ -> ℝ, f(x) = 3*(x**2) - 2*x + 4
If you've used modern Computer Algebra System calculators, they often have similar notation:
# Texas Instruments Nspire 3⋅x² − 2⋅x + 4 -> y
(except they have a proper arrow too, not just ASCII hyphen greater than).
So there is definitely some aesthetic advantage to the arrow if you're used to maths notation, and if Python had it, I'd use it.
But it doesn't scale up to multi-statement functions, and doesn't bring any new functionality into the language, so I'm not convinced that its worth adding as a mere synonym for def or lambda or both.
-- Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/SIY32P... Code of Conduct: http://python.org/psf/codeofconduct/
-- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/
Also: I know there are several modern computer languages that use arrows to represent anonymous functions (JS, Kotlin, Scala...). I also personally remember using (and teaching) Maple in the mid-90s, which used arrows to define functions: https://www.maplesoft.com/support/help/Maple/view.aspx?path=operators/functi... I used to find it perfectly natural. (There is obviously a fundamental difference here: Maple's functions are symbolic, while Python's are procedural. Maple also has procedures which can't be manipulated symbolically). S. On Tue, Feb 23, 2021 at 10:57 AM Stéfane Fermigier <sf@fermigier.com> wrote:
Hi,
My personal opinion is that arrows or even fat arrows would be a nice addition to the Python language for anonymous functions.
I cringe a bit every time I have to write "lambda x: ..." (and even more for parameter-less "lambda: ...").
I have a background in math so I find arrow notation very natural. I have studied a bit lambda calculus, so I can relate to a notation inspired by it too, but I believe:
1) That for it to be elegant, it should be more concise e.g. "ƛx: .." not "lambda x: ..." (but Python is not APL and I don't believe we are ready to introduce non-ascii unicode notations in the language).
2) More importantly, I believe most people are more familiar with the arrow notation than the lambda notation (lambda calculus is, AFAIK, only taught in advanced logic or CS courses at the University).
S.
On Tue, Feb 23, 2021 at 10:26 AM Steven D'Aprano <steve@pearwood.info> wrote:
On Mon, Feb 15, 2021 at 09:29:45AM -0800, Guido van Rossum wrote:
Proposals like this always baffle me. Python already has both anonymous and named functions. They are spelled with 'lambda' and 'def', respectively. What good would it do us to create an alternate spelling for 'def'? [...]
I think that the desire probably comes from thinking of short mathematical functions where the body is a simple expression, like in maths:
def f(x): return 3*(x**2) - 2*x + 4
is kinda clunky and not very maths-like compared to:
f(x) -> 3*(x**2) - 2*x + 4
which is suggestive of function notation:
f : ℝ -> ℝ, f(x) = 3*(x**2) - 2*x + 4
If you've used modern Computer Algebra System calculators, they often have similar notation:
# Texas Instruments Nspire 3⋅x² − 2⋅x + 4 -> y
(except they have a proper arrow too, not just ASCII hyphen greater than).
So there is definitely some aesthetic advantage to the arrow if you're used to maths notation, and if Python had it, I'd use it.
But it doesn't scale up to multi-statement functions, and doesn't bring any new functionality into the language, so I'm not convinced that its worth adding as a mere synonym for def or lambda or both.
-- Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/SIY32P... Code of Conduct: http://python.org/psf/codeofconduct/
-- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/
-- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/
On Tue, Feb 23, 2021 at 11:27:12AM +0100, Stéfane Fermigier wrote:
Also: I know there are several modern computer languages that use arrows to represent anonymous functions (JS, Kotlin, Scala...).
Javascript: first release was 1995, making it 25 years old. It's older than most Javascript programmers. Kotlin is only 9 years old. But Scala is 17 years old. (By the way, Julia calls the -> arrow "the stab operator". I think that's amusing.) Python has a long history of taking inspiration from other languages, but we've had anonymous functions for longer than Javascript has existed. This proposed arrow function would just be an alternative spelling for the same thing. It adds no more power, and no more expressiveness to the language. It would be just one more thing to learn, one more decision to make ("lambda or arrow?"), one more question to be asked a thousand times ("what's the difference between lambda and arrow?"). -- Steve
Hello, On Tue, 23 Feb 2021 23:29:33 +1100 Steven D'Aprano <steve@pearwood.info> wrote:
On Tue, Feb 23, 2021 at 11:27:12AM +0100, Stéfane Fermigier wrote:
Also: I know there are several modern computer languages that use arrows to represent anonymous functions (JS, Kotlin, Scala...).
Javascript: first release was 1995, making it 25 years old. It's older than most Javascript programmers.
Kotlin is only 9 years old. But Scala is 17 years old.
(By the way, Julia calls the -> arrow "the stab operator". I think that's amusing.)
Python has a long history of taking inspiration from other languages, but we've had anonymous functions for longer than Javascript has existed. This proposed arrow function would just be an alternative spelling for the same thing. It adds no more power, and no more expressiveness to the language.
It would be just one more thing to learn, one more decision to make ("lambda or arrow?"), one more question to be asked a thousand times ("what's the difference between lambda and arrow?").
So, (unlike JS) we should make sure that there's no (semantic) difference between lambda and arrow functions, and the answer to "which?" should be "what you want or whatever your boss says". (Btw, syntactically, there may be difference. I hope that we'll eventually extend lambda to multiline, I'm not so sure about arrow. Of course, with braces syntax variant both will be multiline). [] -- Best regards, Paul mailto:pmiscml@gmail.com
I was quite feeling pretty positive about the 'stab' (thanks Steve for this term!) operator idea, until I tried out some examples locally, and it just feels a bit too out-of-place in python, for me (100% subjective opinion here). Having used stabs and compact closure syntax in various languages: swift, c++, javascript, I'd assumed that the joy of just writing `c=>c.foo()` would translate well to python (sometimes lambda x: x.foo() just seems too cumbersome to write out, even if this is a lazy feeling, it's real). But, despite trying a few variants: ->, =>, different whitespace, etc.. , they all still felt non-ideal. I think the main difference, for me, is that the other languages that have adoped this syntax all rely much more on symbols (non-textual tokens) for control flow and structure. (braces, ternary operators, block syntax, etc..) so adding in another non-textual token that also has structural meaning feels natural. You're already 'reading' the symbols to understand what the language is doing, so there are no big surprises when stabs come along. With python there are very few (any?) purely symbolic control flow tokens, and so I naturally expect words to be present to indicate what's going on. Suddenly there's a symbol that indicates a new control structure, and it risks getting lost in the noise. On balance, I'd probably end up using stabs if they were added to Python, but having tried out a few examples on existing code, no longer think it's worth adding them. Thanks Steve On Tue, Feb 23, 2021 at 1:01 PM Paul Sokolovsky <pmiscml@gmail.com> wrote:
Hello,
On Tue, 23 Feb 2021 23:29:33 +1100 Steven D'Aprano <steve@pearwood.info> wrote:
On Tue, Feb 23, 2021 at 11:27:12AM +0100, Stéfane Fermigier wrote:
Also: I know there are several modern computer languages that use arrows to represent anonymous functions (JS, Kotlin, Scala...).
Javascript: first release was 1995, making it 25 years old. It's older than most Javascript programmers.
Kotlin is only 9 years old. But Scala is 17 years old.
(By the way, Julia calls the -> arrow "the stab operator". I think that's amusing.)
Python has a long history of taking inspiration from other languages, but we've had anonymous functions for longer than Javascript has existed. This proposed arrow function would just be an alternative spelling for the same thing. It adds no more power, and no more expressiveness to the language.
It would be just one more thing to learn, one more decision to make ("lambda or arrow?"), one more question to be asked a thousand times ("what's the difference between lambda and arrow?").
So, (unlike JS) we should make sure that there's no (semantic) difference between lambda and arrow functions, and the answer to "which?" should be "what you want or whatever your boss says".
(Btw, syntactically, there may be difference. I hope that we'll eventually extend lambda to multiline, I'm not so sure about arrow. Of course, with braces syntax variant both will be multiline).
[]
-- Best regards, Paul mailto:pmiscml@gmail.com _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/QKPHHK... Code of Conduct: http://python.org/psf/codeofconduct/
Hello, On Tue, 23 Feb 2021 13:24:10 +0000 Stestagg <stestagg@gmail.com> wrote:
I was quite feeling pretty positive about the 'stab' (thanks Steve for this term!) operator idea, until I tried out some examples locally, and it just feels a bit too out-of-place in python, for me (100% subjective opinion here).
Having used stabs and compact closure syntax in various languages: swift, c++, javascript, I'd assumed that the joy of just writing `c=>c.foo()` would translate well to python (sometimes lambda x: x.foo() just seems too cumbersome to write out, even if this is a lazy feeling, it's real). But, despite trying a few variants: ->, =>, different whitespace, etc.. , they all still felt non-ideal.
I think the main difference, for me, is that the other languages that have adoped this syntax all rely much more on symbols (non-textual tokens) for control flow and structure. (braces, ternary operators, block syntax, etc..) so adding in another non-textual token that also has structural meaning feels natural. You're already 'reading' the symbols to understand what the language is doing, so there are no big surprises when stabs come along.
a) Python uses "non-textual tokens" for its operators too. b) And from all the above, the opposite conclusion springs - while in other languages "=>" would be lost in "character soup", in Python it would stand out well enough.
With python there are very few (any?) purely symbolic control flow tokens, and so I naturally expect words to be present to indicate what's going on. Suddenly there's a symbol that indicates a new control structure, and it risks getting lost in the noise.
"=>" is not a "control structure". It's a functional abstraction operator. It takes an expression and abstracts it to a function. While an expression is always evaluated "here and now", a function can be passed somewhere else. All that stuff is from functional programming paradigm. Thinking about it in terms of imperative programming ("control structures") may be not that helpful. [] -- Best regards, Paul mailto:pmiscml@gmail.com
The natural way in Python to write an anonymous function would be to simply drop the name in a regular function definition: def (a): return a**2 The lambda notation is less verbose and closer to computer science theory, though: lambda a: a**2 FWIW: I don't understand why people are so unhappy with lambdas. There isn't all that much use for lambdas in Python anyway. Most of the time, a named function will result in more readable code. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 23 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/
Hello, On Tue, 23 Feb 2021 15:07:50 +0100 "M.-A. Lemburg" <mal@egenix.com> wrote: []
FWIW: I don't understand why people are so unhappy with lambdas.
I don't think that people are unhappy with lambdas. I think that people are *so* happy with lambdas, that want even shorter notation for them.
There isn't all that much use for lambdas in Python anyway. Most of the time, a named function will result in more readable code.
-- Marc-Andre Lemburg eGenix.com
[] -- Best regards, Paul mailto:pmiscml@gmail.com
On Tue, 23 Feb 2021 at 14:10, M.-A. Lemburg <mal@egenix.com> wrote:
The natural way in Python to write an anonymous function would be to simply drop the name in a regular function definition:
def (a): return a**2
The lambda notation is less verbose and closer to computer science theory, though:
lambda a: a**2
FWIW: I don't understand why people are so unhappy with lambdas. There isn't all that much use for lambdas in Python anyway. Most of the time, a named function will result in more readable code.
Typically because they are simple expressions like the a**2 you used above. def a_squared(a): return a**2 is way over the top. Thinking about it, maybe the *real* solution here is to use one of the "placeholder variable" libraries on PyPI - there's "placeholder" which I found on a quick search: from placeholder import _ # single underscore _.age < 18 # lambda obj: obj.age < 18 _[key] ** 2 # lambda obj: obj[key] ** 2 Some people will hate this sort of thing - probably the same people who can't see why anyone has a problem with lambda - but it doesn't need a language change, and it's available now. I guess I've convinced myself here - we already have shorter alternatives to lambda, so why add a new built-in one? Paul
On 23.02.2021 15:29, Paul Moore wrote:
On Tue, 23 Feb 2021 at 14:10, M.-A. Lemburg <mal@egenix.com> wrote:
The natural way in Python to write an anonymous function would be to simply drop the name in a regular function definition:
def (a): return a**2
The lambda notation is less verbose and closer to computer science theory, though:
lambda a: a**2
FWIW: I don't understand why people are so unhappy with lambdas. There isn't all that much use for lambdas in Python anyway. Most of the time, a named function will result in more readable code.
Typically because they are simple expressions like the a**2 you used above.
def a_squared(a): return a**2
is way over the top.
Fair enough. Although as soon as you use the same such function more than once in your application, giving it a name does make sense :-)
Thinking about it, maybe the *real* solution here is to use one of the "placeholder variable" libraries on PyPI - there's "placeholder" which I found on a quick search:
from placeholder import _ # single underscore
_.age < 18 # lambda obj: obj.age < 18 _[key] ** 2 # lambda obj: obj[key] ** 2
Some people will hate this sort of thing - probably the same people who can't see why anyone has a problem with lambda - but it doesn't need a language change, and it's available now.
I guess I've convinced myself here - we already have shorter alternatives to lambda, so why add a new built-in one?
People should have a look at the operator module. It's full of short (and fast) functions for many things you often write lambdas for: https://docs.python.org/3/library/operator.html -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 23 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/
On Tue, 23 Feb 2021 at 15:52, M.-A. Lemburg <mal@egenix.com> wrote:
On 23.02.2021 15:29, Paul Moore wrote:
On Tue, 23 Feb 2021 at 14:10, M.-A. Lemburg <mal@egenix.com> wrote:
The natural way in Python to write an anonymous function would be to simply drop the name in a regular function definition:
def (a): return a**2
The lambda notation is less verbose and closer to computer science theory, though:
lambda a: a**2
FWIW: I don't understand why people are so unhappy with lambdas. There isn't all that much use for lambdas in Python anyway. Most of the time, a named function will result in more readable code.
Typically because they are simple expressions like the a**2 you used above.
def a_squared(a): return a**2
is way over the top.
Fair enough. Although as soon as you use the same such function more than once in your application, giving it a name does make sense :-)
Thinking about it, maybe the *real* solution here is to use one of the "placeholder variable" libraries on PyPI - there's "placeholder" which I found on a quick search:
from placeholder import _ # single underscore
_.age < 18 # lambda obj: obj.age < 18 _[key] ** 2 # lambda obj: obj[key] ** 2
Some people will hate this sort of thing - probably the same people who can't see why anyone has a problem with lambda - but it doesn't need a language change, and it's available now.
I guess I've convinced myself here - we already have shorter alternatives to lambda, so why add a new built-in one?
People should have a look at the operator module. It's full of short (and fast) functions for many things you often write lambdas for:
Definitely. But in cases like this (where brevity and matching the form of an expression is considered important) `partial(add, 2)` doesn't really compare to `lambda x: x+2` (or `x -> x+2`, or `_+2` if you like placeholders). And even using functools.partial, the operator module won't be able to replace `lambda x: x*x` (you can't even transform it to `x**2` and use partial, because the constant is the right hand argument). It's all very subjective, of course. Paul
On 2/23/21 7:57 AM, Paul Sokolovsky wrote:
Hello,
On Tue, 23 Feb 2021 23:29:33 +1100 Steven D'Aprano <steve@pearwood.info> wrote:
On Tue, Feb 23, 2021 at 11:27:12AM +0100, Stéfane Fermigier wrote:
Also: I know there are several modern computer languages that use arrows to represent anonymous functions (JS, Kotlin, Scala...). Javascript: first release was 1995, making it 25 years old. It's older than most Javascript programmers.
Kotlin is only 9 years old. But Scala is 17 years old.
(By the way, Julia calls the -> arrow "the stab operator". I think that's amusing.)
Python has a long history of taking inspiration from other languages, but we've had anonymous functions for longer than Javascript has existed. This proposed arrow function would just be an alternative spelling for the same thing. It adds no more power, and no more expressiveness to the language.
It would be just one more thing to learn, one more decision to make ("lambda or arrow?"), one more question to be asked a thousand times ("what's the difference between lambda and arrow?"). So, (unlike JS) we should make sure that there's no (semantic) difference between lambda and arrow functions, and the answer to "which?" should be "what you want or whatever your boss says".
(Btw, syntactically, there may be difference. I hope that we'll eventually extend lambda to multiline, I'm not so sure about arrow. Of course, with braces syntax variant both will be multiline).
My first thought to the idea of making an alternate syntax is the line from the Zen: There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. This says that if the 'arrow' is a new alternate way of writing lambda, then lambda needs to be, at least informally, deprecated and declared not to be that obvious way to do it (but it can't be actually removed for a long time for backwards compatibility reasons). Note, I thought that lambda was currently 'multi-line', it just isn't multi-statement, just a single expression, that could flow to following lines (and since often used inside a function call, being inside the '(' makes the continuation to the next line automatic) -- Richard Damon
Hello, On Tue, 23 Feb 2021 09:35:58 -0500 Richard Damon <Richard@Damon-Family.org> wrote: []
My first thought to the idea of making an alternate syntax is the line from the Zen:
There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch.
This says that if the 'arrow' is a new alternate way of writing lambda, then lambda needs to be, at least informally, deprecated and declared not to be that obvious way to do it (but it can't be actually removed for a long time for backwards compatibility reasons).
No more than "+" deprecates __add__, or vice-versa. And no more than various pop-up novelties (we now have more than one) deprecate sacred '"%s" % var' syntax.
Note, I thought that lambda was currently 'multi-line', it just isn't multi-statement, just a single expression, that could flow to following lines (and since often used inside a function call, being inside the '(' makes the continuation to the next line automatic)
Yes, people who colloquially say "multi-line", formally mean multi-statement. (Alternatively, they mean "multi-line without tricks".) [] -- Best regards, Paul mailto:pmiscml@gmail.com
On 2/23/21 10:07 AM, Paul Sokolovsky wrote:
Hello,
On Tue, 23 Feb 2021 09:35:58 -0500 Richard Damon <Richard@Damon-Family.org> wrote:
[]
My first thought to the idea of making an alternate syntax is the line from the Zen:
There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch.
This says that if the 'arrow' is a new alternate way of writing lambda, then lambda needs to be, at least informally, deprecated and declared not to be that obvious way to do it (but it can't be actually removed for a long time for backwards compatibility reasons). No more than "+" deprecates __add__, or vice-versa. And no more than various pop-up novelties (we now have more than one) deprecate sacred '"%s" % var' syntax.
The difference with + is that it NEVER was the case that the 'preferred' way to add two values was with a direct call to __add__ (it was just an internal implmentation detail for the operator). As far as formatting strings, yes, there are multiple ways to do similar things, but there are also significant differences between them. If we look at 'f-strings' as the example, I beleive f-strings are now considered the 'preferred obvious' way to do it, when it is applicable, but that there are still significant cases where you can't use the f-string, because it is a 'compile' time construct. For things like translation strings, where the string comes from some string store, and at run time combined with the variable, you still need do this with the older % or .format() method. As far as between % or .format(), I think the documentation is fairly clear that the % method is 'old' and if not 'formally' deprecated, is no longer considered the 'obvious' way to do it (even if some people will still do it that way for the simplest cases).
Note, I thought that lambda was currently 'multi-line', it just isn't multi-statement, just a single expression, that could flow to following lines (and since often used inside a function call, being inside the '(' makes the continuation to the next line automatic) Yes, people who colloquially say "multi-line", formally mean multi-statement. (Alternatively, they mean "multi-line without tricks".)
People colloquially using the wrong words shouldn't get surprised when they get corrected. It isn't a 'trick' to make a Python expression 'multi-line', it is just standard Python formatting. Now, if lambda can 'grow up' to be a 'multi-statement expression' (whch I think is part of the issue) then perhaps there is room for both lambda and 'arrow functions', just like string formatting has both f-strings and .format(). That is a big 'IF', as putting statement-blocks into code as pieces of an expression, is a cognitive barrier, and may well require a syntax change (perhaps using an anonymous def inside the expression), and I am not sure how common it can be found (I know in C, it is only available as a semi-common extension in some compilers). Also note, that I am not saying that 'arrow-functions' can't happen, just that if they are created, a natural consequence is that, like with .format(), the 'old' (lambda) way will need to be marked as 'old', and not the current obvious way. -- Richard Damon
On Tue, Feb 23, 2021 at 6:13 PM Richard Damon <Richard@damon-family.org> wrote:
Also note, that I am not saying that 'arrow-functions' can't happen, just that if they are created, a natural consequence is that, like with .format(), the 'old' (lambda) way will need to be marked as 'old', and not the current obvious way.
If there is a consensus that arrows are better enough that lambdas, and arrows happen, lambdas will be considered 'old' and automated converters such as pyupgrade will be quick to replace lambdas (and people publishing libraries will have to wait until the EOL of the older versions of Python before being able to run it). And if, otherwise, there is no such consensus, the change will never happen. Same as u"xxx" versus Unicode("xxx"), x**y vs pow(x, y), x @ y vs. matmul(x, y), etc. S. -- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/
On 23/02/2021 17:46, Stéfane Fermigier wrote:
On Tue, Feb 23, 2021 at 6:13 PM Richard Damon <Richard@damon-family.org <mailto:Richard@damon-family.org>> wrote:
Also note, that I am not saying that 'arrow-functions' can't happen, just that if they are created, a natural consequence is that, like with .format(), the 'old' (lambda) way will need to be marked as 'old', and not the current obvious way.
If there is a consensus that arrows are better enough that lambdas, and arrows happen, lambdas will be considered 'old' and automated converters such as pyupgrade will be quick to replace lambdas (and people publishing libraries will have to wait until the EOL of the older versions of Python before being able to run it).
And if, otherwise, there is no such consensus, the change will never happen.
Same as u"xxx" versus Unicode("xxx"), x**y vs pow(x, y), x @ y vs. matmul(x, y), etc.
S.
As far as I know, there is no case of valid syntax using 'lambda' where replacing 'lambda' by 'def' results in valid syntax. Can anyone provide a counter-example? If not, I would support allowing 'def' as an alternative to 'lambda' (allowing 'def' to ultimately become the recommended usage). (I'm -0.5 on adding an alternative arrow syntax, but that's a purely subjective opinion.) Rob Cliffe
On 2/23/21 5:01 PM, Rob Cliffe via Python-ideas wrote:
On 23/02/2021 17:46, Stéfane Fermigier wrote:
On Tue, Feb 23, 2021 at 6:13 PM Richard Damon <Richard@damon-family.org <mailto:Richard@damon-family.org>> wrote:
Also note, that I am not saying that 'arrow-functions' can't happen, just that if they are created, a natural consequence is that, like with .format(), the 'old' (lambda) way will need to be marked as 'old', and not the current obvious way.
If there is a consensus that arrows are better enough that lambdas, and arrows happen, lambdas will be considered 'old' and automated converters such as pyupgrade will be quick to replace lambdas (and people publishing libraries will have to wait until the EOL of the older versions of Python before being able to run it).
And if, otherwise, there is no such consensus, the change will never happen.
Same as u"xxx" versus Unicode("xxx"), x**y vs pow(x, y), x @ y vs. matmul(x, y), etc.
S.
As far as I know, there is no case of valid syntax using 'lambda' where replacing 'lambda' by 'def' results in valid syntax. Can anyone provide a counter-example? If not, I would support allowing 'def' as an alternative to 'lambda' (allowing 'def' to ultimately become the recommended usage). (I'm -0.5 on adding an alternative arrow syntax, but that's a purely subjective opinion.) Rob Cliffe
My one thought is that if one issue with making a multi-statement lambda is that the parser can't tell if it needs a statement block or an expression (for current lambda), that def in this format could be the syntax to get to the multi-statement 'lambda'. -- Richard Damon
On Tue, Feb 23, 2021, at 17:01, Rob Cliffe via Python-ideas wrote:
As far as I know, there is no case of valid syntax using 'lambda' where replacing 'lambda' by 'def' results in valid syntax. Can anyone provide a counter-example? If not, I would support allowing 'def' as an alternative to 'lambda' (allowing 'def' to ultimately become the recommended usage).
I have an objection to this: "def" is short for define, and a lambda does not produce a definition. This isn't just about saving keystrokes, and even if it were, saving only three would not be worth it for a syntax that is just as confusing as the existing one.
On 2021-02-24 06:04, Random832 wrote:
I have an objection to this: "def" is short for define, and a lambda does not produce a definition. This isn't just about saving keystrokes, and even if it were, saving only three would not be worth it for a syntax that is just as confusing as the existing one.
I'd argue it defines a function or method, which is what happens when used, or proposed to be used. Also, I don't believe the confusion mentioned was regarding syntax, but rather a word that most people have never heard before. -Mike
On Wed, Feb 24, 2021 at 06:46:21PM -0800, Mike Miller wrote:
Also, I don't believe the confusion mentioned was regarding syntax, but rather a word that most people have never heard before.
When I started learning Python, back when 1.5 was new and cutting edge, it was an embarassingly long time before I twigged that "def" was short for "define". I thought it was just a made up word like "grep" and "glob". -- Steve
On 2021-02-25 01:05, Steven D'Aprano wrote:
On Wed, Feb 24, 2021 at 06:46:21PM -0800, Mike Miller wrote:
Also, I don't believe the confusion mentioned was regarding syntax, but rather a word that most people have never heard before.
When I started learning Python, back when 1.5 was new and cutting edge, it was an embarassingly long time before I twigged that "def" was short for "define". I thought it was just a made up word like "grep" and "glob".
Glob is a word, a round lump of stuff. I may not have known exactly what it meant on first encounter, but I had a gut understanding, in the onomatopoeia sense. Around the same time as you, I figured out "def" at first glance the afternoon when taking the tutorial. I've missed many other things many times so perhaps we should chalk it up to chance. In any case, glad we don't have to use definition. I do nominate twig for anything that fits. -Mike
On 24/02/2021 14:04, Random832 wrote:
On Tue, Feb 23, 2021, at 17:01, Rob Cliffe via Python-ideas wrote:
As far as I know, there is no case of valid syntax using 'lambda' where replacing 'lambda' by 'def' results in valid syntax. Can anyone provide a counter-example? If not, I would support allowing 'def' as an alternative to 'lambda' (allowing 'def' to ultimately become the recommended usage). I have an objection to this: "def" is short for define, and a lambda does not produce a definition. Yes it does. It defines a function just as `def ` does:
def f(): pass g = lambda : None print(f) print(g) Output: <function f at 0x016B87C0> <function <lambda> at 0x02423190>
This isn't just about saving keystrokes, and even if it were, saving only three would not be worth it for a syntax that is just as confusing as the existing one. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/DQA6G2... Code of Conduct: http://python.org/psf/codeofconduct/
On Wed, Feb 24, 2021 at 4:13 AM Richard Damon <Richard@damon-family.org> wrote:
As far as between % or .format(), I think the documentation is fairly clear that the % method is 'old' and if not 'formally' deprecated, is no longer considered the 'obvious' way to do it (even if some people will still do it that way for the simplest cases).
Not really - both forms have their places. You use .format() when you need to be able to reorder arguments, you use percent formatting when you want a compact and simple notation. It's like how we have both string methods and regular expressions - neither one deprecates the other. ChrisA
Both '%' and .format() support both positional and named arguments. There are probably a few use cases for .format() (vs. f-strings) but overall I don't believe there is much reasons left to prefer %. Note that the existence, and popularity, of tools like flynt and pyupgrade (that convert % and .format() directives to f-strings automatically) supports this affirmation. I found the 'un-fstring' project on pypi that does the reverse, but it's use case, as advertised in the README, is clear: "Sometimes, unfortunately, you need to write code that is compatible with Python 3.5"... S. On Tue, Feb 23, 2021 at 6:50 PM Chris Angelico <rosuav@gmail.com> wrote:
On Wed, Feb 24, 2021 at 4:13 AM Richard Damon <Richard@damon-family.org> wrote:
As far as between % or .format(), I think the documentation is fairly clear that the % method is 'old' and if not 'formally' deprecated, is no longer considered the 'obvious' way to do it (even if some people will still do it that way for the simplest cases).
Not really - both forms have their places. You use .format() when you need to be able to reorder arguments, you use percent formatting when you want a compact and simple notation. It's like how we have both string methods and regular expressions - neither one deprecates the other.
ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/UEZIQ5... Code of Conduct: http://python.org/psf/codeofconduct/
-- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/
On 23 Feb 2021, at 18:08, Stéfane Fermigier <sf@fermigier.com> wrote:
Both '%' and .format() support both positional and named arguments.
There are probably a few use cases for .format() (vs. f-strings) but overall I don't believe there is much reasons left to prefer %.
I18n you can translate a f string. Barry
Note that the existence, and popularity, of tools like flynt and pyupgrade (that convert % and .format() directives to f-strings automatically) supports this affirmation.
I found the 'un-fstring' project on pypi that does the reverse, but it's use case, as advertised in the README, is clear: "Sometimes, unfortunately, you need to write code that is compatible with Python 3.5"...
S.
On Tue, Feb 23, 2021 at 6:50 PM Chris Angelico <rosuav@gmail.com> wrote: On Wed, Feb 24, 2021 at 4:13 AM Richard Damon <Richard@damon-family.org> wrote:
As far as between % or .format(), I think the documentation is fairly clear that the % method is 'old' and if not 'formally' deprecated, is no longer considered the 'obvious' way to do it (even if some people will still do it that way for the simplest cases).
Not really - both forms have their places. You use .format() when you need to be able to reorder arguments, you use percent formatting when you want a compact and simple notation. It's like how we have both string methods and regular expressions - neither one deprecates the other.
ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/UEZIQ5... Code of Conduct: http://python.org/psf/codeofconduct/
-- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/TTOMZH... Code of Conduct: http://python.org/psf/codeofconduct/
On 23 Feb 2021, at 21:42, Barry <barry@barrys-emacs.org> wrote:
On 23 Feb 2021, at 18:08, Stéfane Fermigier <sf@fermigier.com> wrote:
Both '%' and .format() support both positional and named arguments.
There are probably a few use cases for .format() (vs. f-strings) but overall I don't believe there is much reasons left to prefer %.
I18n you can translate a f string.
Sigh... you *cannot* translate an f string. Barry
Barry
Note that the existence, and popularity, of tools like flynt and pyupgrade (that convert % and .format() directives to f-strings automatically) supports this affirmation.
I found the 'un-fstring' project on pypi that does the reverse, but it's use case, as advertised in the README, is clear: "Sometimes, unfortunately, you need to write code that is compatible with Python 3.5"...
S.
On Tue, Feb 23, 2021 at 6:50 PM Chris Angelico <rosuav@gmail.com> wrote: On Wed, Feb 24, 2021 at 4:13 AM Richard Damon <Richard@damon-family.org> wrote:
As far as between % or .format(), I think the documentation is fairly clear that the % method is 'old' and if not 'formally' deprecated, is no longer considered the 'obvious' way to do it (even if some people will still do it that way for the simplest cases).
Not really - both forms have their places. You use .format() when you need to be able to reorder arguments, you use percent formatting when you want a compact and simple notation. It's like how we have both string methods and regular expressions - neither one deprecates the other.
ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/UEZIQ5... Code of Conduct: http://python.org/psf/codeofconduct/
-- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/TTOMZH... Code of Conduct: http://python.org/psf/codeofconduct/
Hello, On Tue, 23 Feb 2021 12:11:00 -0500 Richard Damon <Richard@Damon-Family.org> wrote: []
them. If we look at 'f-strings' as the example, I beleive f-strings are now considered the 'preferred obvious' way to do it, when it is
It's a common mistake. %-formatting was "preferred obvious" 30 years ago, and is "preferred obvious" now (exactly because it's stable, not a random jumping novelty). But if you want to use f-strings, now you can. The same situation would be with "lambda" - it would remain "preferred obvious", but people who need arrow functions, will be able to use them. [] -- Best regards, Paul mailto:pmiscml@gmail.com
On Tue, Feb 23, 2021 at 1:34 PM Steven D'Aprano <steve@pearwood.info> wrote:
On Tue, Feb 23, 2021 at 11:27:12AM +0100, Stéfane Fermigier wrote:
Also: I know there are several modern computer languages that use arrows to represent anonymous functions (JS, Kotlin, Scala...).
Javascript: first release was 1995, making it 25 years old. It's older than most Javascript programmers.
I was, implicitly, talking about "modern JavaScript" (which one could argue is post-ES6 or at least post-ES5 JavaScript) since arrows were introduced in ES6. In this sense, "modern JavaScript" (or post-ES6 JavaScript) is a modern computer language. Another point: ES6 gained arrows because of Scala's influence, I'm pretty sure. But also because of the influence of CoffeScript whose motto was to be "Just JavaScript" - with an alternative syntax. And this alternative syntax was eventually subsumed by JavaScript itself. This proposed arrow function would just be an alternative
spelling for the same thing. It adds no more power, and no more expressiveness to the language.
Indeed. This makes the proposal much less controversial IMHO. This wouldn't be the first time some syntactic sugar would be added to the language to bring its syntax closer to traditional mathematical notation. See for instance:
pow(2,3) 8 2**3 8
Or the matrix multiplication operator (@). Or complex numbers:
complex(0,1) 1j 1j 1j
S. -- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/
On Tue, 23 Feb 2021 at 09:25, Steven D'Aprano <steve@pearwood.info> wrote:
On Mon, Feb 15, 2021 at 09:29:45AM -0800, Guido van Rossum wrote:
Proposals like this always baffle me. Python already has both anonymous and named functions. They are spelled with 'lambda' and 'def', respectively. What good would it do us to create an alternate spelling for 'def'? [...]
I think that the desire probably comes from thinking of short mathematical functions where the body is a simple expression, like in maths:
[...]
So there is definitely some aesthetic advantage to the arrow if you're used to maths notation, and if Python had it, I'd use it.
Yes, this is precisely my instinct as well. In addition, for whatever reason (and it's purely subjective, I won't try to defend it) I find "lambda" as a keyword somewhat alien in Python, where most other keywords are short terms or abbreviations of terms (and the terms are mostly non-technical English words - "with", "for", "def(ine)", "class", ...). So every time I use a lambda expression, it feels mildly unnatural to me, and I look for a "better way" of expressing my intent. But having a mathematical background, functional and comprehension styles feel natural to me, which introduces a tension - so, for example, I recently wrote some code that included the following: squares = set(takewhile(lambda sq: sq <= 2 * end, map(lambda x: x * x, count()))) A procedural version would be squares = set() x = 1 while True: sq = x * x if sq > 2 * end: break squares.add(sq) x += 1 and a *lot* of people would say this is easier to read, but IMO, both should have a comment explaining what "squares" is, and the itertools-based version took me less time to write, and ensure I'd got correct. I'd find a version using "arrow notation" squares = set(takewhile(sq => (sq <= 2 * end), map(x => x * x, count()))) easier to read than the lambda version (personally I prefer => over ->, but that's a detail) even though I needed to add parentheses to (sq <= 2 * end) to make it clear what was the expression and what was the argument. Honestly, none of these scream to me "the set of squares less than end * 2", though, so it's difficult to say any one of them is the "obvious" choice. But I'd probably order them as =>, lambda, procedural (from best to worst). This is when writing that code in a Jupyter notebook as part of some exploratory work. If this were production-level code where others would be maintaining it, I'd write a standalone function that wrapped the procedural code, give it a name and a docstring, and add some tests to it. But not all code is like that (not even all "important" code) so sometimes the one-liners make sense.
But it doesn't scale up to multi-statement functions, and doesn't bring any new functionality into the language, so I'm not convinced that its worth adding as a mere synonym for def or lambda or both.
Yep, it's a difficult call. I suspect that if Python had been developed now, it would have followed the trend of using arrow notation. But adding it as a synonym for the existing lambda is nowhere near as obvious a choice. Paul
On 15/02/2021 16:32, David Mertz wrote:
On Mon, Feb 15, 2021 at 4:19 PM Guido van Rossum <guido@python.org <mailto:guido@python.org>> wrote:
Okay, here’s my dilemma. It looks like this thread wants to devise a new syntax for lambda, using e.g. (x, y) -> x+y, or the same with =>. That’s great, but doesn’t open new vistas. OTOH, for people using type annotations, a much more pressing issue is an alternative for typing.Callable that is more readable, and supports extra features that Callable doesn’t, like keyword args, varargs, and pos-only.
FWIW, I *do not* want an alternate spelling for lambda. +1
If your time machine were still working, and you could go back to 1991 to change the spelling, yes I might like that. For that matter, if someone had a good spelling for multi-line lambdas, I might like that. Or *maybe* some other difference in behavior, but nothing comes immediately to mind. +1
But allowing a few cryptic punctuation symbols to express an anonymous function while still retaining "the name of a cryptic greek letter" to do exactly the same thing seems like a strong non-goal. +1.
That said, if I had to look at one, I'd like '->' much better than '=>'.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/6MWEHX... Code of Conduct: http://python.org/psf/codeofconduct/
On 2021-02-14 00:54, Paul Sokolovsky wrote:
There're 2 things about that from an experienced JavaScript-hater (but a pragmatic guy otherwise):
1. We aren't talking about all of JavaScript, but a recent features added to JS. 2. JS has real money being poured into it, and no longer designed on two-week vacations, when nobody looks. On the JS committees/proposal author lists are guys who have publications in serious programming language design matters and "grown up" languages, like proverbial Haskell. And they peer-review each other. So, with due understanding of the baseline https://en.wikipedia.org/wiki/Design_by_committee process, some recent features in JS are well-designed.
Maybe, but the problem is that they're cripplingly constrained by their unwillingness to ever remove features or change old behavior. So to the extent that features are "well-designed" they're only well-designed to fit into the crappy design that already exists. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown
participants (23)
-
Abdulla Al Kathiri -
Barry -
Brendan Barnwell -
Cade Brown -
Chris Angelico -
David Mertz -
Greg Ewing -
Guido van Rossum -
Jonathan Goble -
M.-A. Lemburg -
Matthias Bussonnier -
Mike Miller -
Paul Moore -
Paul Sokolovsky -
Random832 -
Richard Damon -
Ricky Teachey -
Rob Cliffe -
Stephen J. Turnbull -
Stestagg -
Steven D'Aprano -
Stéfane Fermigier -
Sven R. Kunze