3 ms·

What I miss the most with python is multi-line closures and "can't put statements in lambdas'. For instance: # Not valid. my_button.on('click', lambda x: r

by phzbOx 15y ago

What I miss the most with python is multi-line closures and "can't put statements in lambdas'. For instance: # Not valid. my_button.on('click', lambda x: raise 'unimplemented') my_button.on('click', lambda _: some_var = 'clicked') I believe the whitespace delimiters is the main reason why we aren't allowed to have multi-lines lambdas. (CoffeeScript proves us wrong on that, but from my experience, multi-lines whitespaced functions look better in CS than in Python.) Also, I'd like to point out that "where's the patch" is really unfair. Python programmers are 'users/customers'. So, it's like if a customer asked for a feature and you'd tell her to implement it..

jashkenas 15y ago
Yep, multi-line functions (lambdas, closures) delimited by whitespace shouldn't be a problem ... but I've heard the same argument made as well. Do you remember where it was that you first read that "whitespace delimiters is the main reason why we aren't allowed to have multi-line lambdas" ?
- phzbOx 15y ago
  I've been arguing for ages about that on #python/freenode. Otherwise, I don't know. Different attempts have been made to include lambdas but it always feel wrong and unpythonic. I believe it's not so much about multi-lines but more about how the standard library is designed. It's mostly imperative/OO and use really few callbacks. Thus, when you try mixing long lambdas, it feels wrong. Unlike in CS with node.js or jQuery (for example), where callbacks are really the way to go.
tizoc 15y ago
I think the reason for asking for the patch was the [PATCH] in the subject.
exDM69 15y ago
>> Also, I'd like to point out that "where's the patch" is really unfair. Python programmers are 'users/customers'. So, it's like if a customer asked for a feature and you'd tell her to implement it.. No they are not customers. They aren't paying anything to anyone nor do the python devs owe him anything. It infuriates me every time someone considers a non-paying (or otherwise contributing) open source software user a customer that's "always right". In general, if you have a feature that you wish to get in an open source project, you start off by making a crude implementation yourself and then go and submit it for peer review and further discussion. If it were a humble feature request, it should have been sent to python-ideas, not python-devs. As it was not really a feature request and it didn't have any examples what the new syntax would look like, it was just an opinion piece that should have gone to his personal blog. Now this jerk just wasted a whole lot of the python core dev team's time, including at least two responses from Guido van Rossum. I'd much more prefer seeing the python devs spending their time on developing python than answering e-mails like this.
pak 15y ago
For a while I thought the OP was building up into a great argument about the loss of expression imposed by WSB, what with all the great rhetoric about patronizing the programmer (a smell that I will agree occasionally lingers around Python language design decisions). But then, the argument rapidly devolved into trifles over editor issues and code review tooling. Those are ultimately low-impact because Python people can always write better editor plugins and code review tools, just as people have had to do for any language that incorporates new syntax ideas. Python's crippled lambdas, like you mentioned, are a much better illustration of where WSB causes irritation down the road. I was looking forward to comparisons with Ruby that highlight the expressiveness that blocks can provide, e.g. def gratuitous_callback_name(bar): while bar(): baz() return meh() foo(gratuitous_callback_name) is clearly not preferable to foo {|bar| baz() while bar(); meh() } and perhaps some demonstrations of how freedom with indentation can lead to more readable code, such as the XCode indentation style for Objective-C vs. the continuation line mess seen in PEP 8 [1]. Also, I would suggest that significant whitespace combined with docstring conventions lead to an unnecessarily complicated algorithm just to strip the whitespace back out [2]: that doesn't smell right either. Similar problems carry over to any Python code that involves defining lots of multiline strings within methods where the whitespace will be significant later (more often than you'd think). Alas, the OP dropped off so fast before even mentioning any of the above--I suspect a troll. [1]: http://www.python.org/dev/peps/pep-0008/ http://www.python.org/dev/peps/pep-0008/ [2]: http://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation http://www.python.org/dev/peps/pep-0257/#handling-docstring-...

by phzbOx 15y ago

jashkenas 15y ago

Yep, multi-line functions (lambdas, closures) delimited by whitespace shouldn't be a problem ... but I've heard the same argument made as well. Do you remember where it was that you first read that "whitespace delimiters is the main reason why we aren't allowed to have multi-line lambdas" ?

phzbOx 15y ago
I've been arguing for ages about that on #python/freenode. Otherwise, I don't know. Different attempts have been made to include lambdas but it always feel wrong and unpythonic. I believe it's not so much about multi-lines but more about how the standard library is designed. It's mostly imperative/OO and use really few callbacks. Thus, when you try mixing long lambdas, it feels wrong. Unlike in CS with node.js or jQuery (for example), where callbacks are really the way to go.

tizoc 15y ago

I think the reason for asking for the patch was the [PATCH] in the subject.

exDM69 15y ago

>> Also, I'd like to point out that "where's the patch" is really unfair. Python programmers are 'users/customers'. So, it's like if a customer asked for a feature and you'd tell her to implement it.. No they are not customers. They aren't paying anything to anyone nor do the python devs owe him anything. It infuriates me every time someone considers a non-paying (or otherwise contributing) open source software user a customer that's "always right". In general, if you have a feature that you wish to get in an open source project, you start off by making a crude implementation yourself and then go and submit it for peer review and further discussion. If it were a humble feature request, it should have been sent to python-ideas, not python-devs. As it was not really a feature request and it didn't have any examples what the new syntax would look like, it was just an opinion piece that should have gone to his personal blog. Now this jerk just wasted a whole lot of the python core dev team's time, including at least two responses from Guido van Rossum. I'd much more prefer seeing the python devs spending their time on developing python than answering e-mails like this.

pak 15y ago

For a while I thought the OP was building up into a great argument about the loss of expression imposed by WSB, what with all the great rhetoric about patronizing the programmer (a smell that I will agree occasionally lingers around Python language design decisions). But then, the argument rapidly devolved into trifles over editor issues and code review tooling. Those are ultimately low-impact because Python people can always write better editor plugins and code review tools, just as people have had to do for any language that incorporates new syntax ideas. Python's crippled lambdas, like you mentioned, are a much better illustration of where WSB causes irritation down the road. I was looking forward to comparisons with Ruby that highlight the expressiveness that blocks can provide, e.g. def gratuitous_callback_name(bar): while bar(): baz() return meh() foo(gratuitous_callback_name) is clearly not preferable to foo {|bar| baz() while bar(); meh() } and perhaps some demonstrations of how freedom with indentation can lead to more readable code, such as the XCode indentation style for Objective-C vs. the continuation line mess seen in PEP 8 [1]. Also, I would suggest that significant whitespace combined with docstring conventions lead to an unnecessarily complicated algorithm just to strip the whitespace back out [2]: that doesn't smell right either. Similar problems carry over to any Python code that involves defining lots of multiline strings within methods where the whitespace will be significant later (more often than you'd think). Alas, the OP dropped off so fast before even mentioning any of the above--I suspect a troll. [1]: http://www.python.org/dev/peps/pep-0008/ http://www.python.org/dev/peps/pep-0008/ [2]: http://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation http://www.python.org/dev/peps/pep-0257/#handling-docstring-...