"What Python needs is an alternative to WSB and can stay Python by still offering WSB to all those who happen to like it."
And that's an argument? Why not include static typing, or single inheritance, GOTO while we're at it? I'm sure there are those who happen to like them.
Well if anything, this is one of the most vocative trolls I have ever read. :)
>> And that's an argument? Why not include static typing, or single inheritance, GOTO while we're at it? I'm sure there are those who happen to like them.
Why is static typing in that list? Unlike single inheritance or GOTO's, static typing is a good thing. Dynamic typing is often used in interpreted languages because once you're writing an interpreter, there's going to be a massive performance hit anyway and dynamic typing won't make it a lot worse. Dynamic typing makes compiling efficient code very difficult.
Of course, a good static typing programming language should have at least some kind of type inference mechanism to allow the programmer to leave out explicit type declarations when a compile can infer them from the program source code.
Boo is a statically typed, type-inferring language for the CLR that has a Python-like syntax. It seems pretty nice, I've written a few toy projects with it.
There's an argument to be made: one can't be all things to everyone. Python is a dynamic language, and adding optional features to make it work differently won't bring the benefits of either way of making things work consistently. Two syntaxes like that troll poster proposed would increase cognitive load, static typing mixed with dynamic typing would add some boilerplate for no real safety.
Simplicity can be a benefit, but there are examples of languages that are either dynamically typed with optional static type annotations and languages that are statically typed but have a special dynamic duck type (that may use something like the invokedynamic opcode in the java bytecode), so why not Python?
Examples:
static typing with optional duck types: Boo.
dynamic typing with optional type annotations: many Lisps, e.g. Racket.
Python can't become static with optional invokedynamic; static typing has to be built from the start. For example, the % operator can't be typed. Optional typing I've seen in Perl, and again it seems like boilerplate for no benefit.
I was thinking more about having optional type annotations to facilitate better optimization in (JIT) compiler based implementations of Python, like PyPy, Jython, IronPython or others. Type annotations may also be useful for doing some static sanity checking.
The first reply pretty much nails it: "where is the patch?"
There's a huge difference between going to a mailing list and asking for (unpopular) features and going ahead and implementing it. Provide a patch, along with test cases and practical use case examples and you're making a point. Abstract rambling with 0 lines of code examples is worthless.
What comes to the actual issue: I'm a huge fan of layout based syntax but I do hate writing white space sensitive parsers. I think Haskell's way of having curlies and semicolons in the core syntax and adding layout as a sugar coating hits a particular sweet spot.
The patch is a red herring. Braces have been explicitly rejected in the past. He needs to convince people that they're a good thing, and a patch isn't going to help. (At least not much compared to the time investment.)
> I think Haskell's way of having curlies and semicolons in the core syntax and adding layout as a sugar coating hits a particular sweet spot.
Whitespace blocks means my editor can not correctly reindent when I shift levels of indentation and instruct the editor to pretty-reformat. This wastes my time because I have to manually sort things out. It also means that things I can't see are affecting my code. It's a pain to work with in Python and a pain to work with in Haskell. My experience is that it's an epically bad idea made attractive by revulsion from C++/Java.
Curlies or Lisp-like curves play a ton nicer with tooling and visual inspection.
It's an ambiguity problem similar to the dangling else. There's no way to automatically tell the editor that I want the statements to go here or there.
edit: Yes, there's a reformat command in emacs. No, it does not work correctly for Python, because the lack of delimiters means it does not have the information it needs to do the job right.
Do you have the appropriate emacs plugins for writing Python? I'm a bit surprised that the code isn't formatted properly with emacs out of the box. Then again, many editors need some sort of addon to be able to cope with whitespace sensitive syntax.
If it were an actual grammatical ambiguity, any editor couldn't get it right but it can't be since the Python parser can understand it.
I see. I never have that problem because when I C-S-<Backspace> and put my cursor at the beginning of the line I want to paste it retains indentation level fine.
edit: What version of emacs are you using? Are you using python.el or python-mode.el for editing Python? python.el handles try/except, if/else, etc., etc., indentation pretty marvelously.
edit2: If you'd rather talk about this out-of-band I'm on freenode as mdeboard or my email address is in my profile.
23.3.x and python.el. It's very stock. What function does C-S-backspace give you? I see kill-whole-line on my install. Once I am writing in a block, the indents work fine, but... I can't paste something into a block and whack the 'reformat all' to come out correctly, especially if it has multiple levels of indentation. Since my code gets reworked substantially while I'm in the middle of it, this wastes my time. Braces are not noise...
It sounds like you need to use the kill ring & pasting from the kill ring more. It preserves indentation levels, and selecting a region then M-x indent-region will handle all this for you.
As a Vim / ST2 user I've never once had to fight with indentation levels. The only time I ever have to even think about them are when cut/copy/pasting code around. And even then it's just a quick re-highlight and spam the indent key one way or the other.
Agreed, but there's a solution.
Emacs recognises the end of a block by using "pass" to end the block. This makes it reindent properly. It's not the official python style, but I prefer to write code that way. Try it, it's not bad.
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..
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" ?
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.
>> 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.
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.
Guido's (somewhat surprising) response, for those too busy to read through:
On Fri, Dec 9, 2011 at 12:26 PM, Cedric Sodhi <manday at gmx.net> wrote:
> IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN
> DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO
> DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING
> SIMILAR, JUST DON'T.
Every single response in this thread so far has ignored this request. The
correct response honoring this should have been deafening silence.
For me, if I had to design a new language today, I would probably use
braces, not because they're better than whitespace, but because pretty much
every other lanugage uses them, and there are more interesting concepts to
distinguish a new language. That said, I don't regret that Python uses
indentation, and the rest I have to say about the topic would violate the
above request.
--Guido van Rossum (python.org/~guido)
38 comments
[ 2.7 ms ] story [ 98.4 ms ] threadPeople who find this problematic need to find another language or stop focusing on trivia.
And that's an argument? Why not include static typing, or single inheritance, GOTO while we're at it? I'm sure there are those who happen to like them.
Well if anything, this is one of the most vocative trolls I have ever read. :)
Why is static typing in that list? Unlike single inheritance or GOTO's, static typing is a good thing. Dynamic typing is often used in interpreted languages because once you're writing an interpreter, there's going to be a massive performance hit anyway and dynamic typing won't make it a lot worse. Dynamic typing makes compiling efficient code very difficult.
Of course, a good static typing programming language should have at least some kind of type inference mechanism to allow the programmer to leave out explicit type declarations when a compile can infer them from the program source code.
Boo is a statically typed, type-inferring language for the CLR that has a Python-like syntax. It seems pretty nice, I've written a few toy projects with it.
Examples: static typing with optional duck types: Boo. dynamic typing with optional type annotations: many Lisps, e.g. Racket.
One benefit is additional optimizations. Many good Lisp implementations take advantage of this.
There's a huge difference between going to a mailing list and asking for (unpopular) features and going ahead and implementing it. Provide a patch, along with test cases and practical use case examples and you're making a point. Abstract rambling with 0 lines of code examples is worthless.
What comes to the actual issue: I'm a huge fan of layout based syntax but I do hate writing white space sensitive parsers. I think Haskell's way of having curlies and semicolons in the core syntax and adding layout as a sugar coating hits a particular sweet spot.
> I think Haskell's way of having curlies and semicolons in the core syntax and adding layout as a sugar coating hits a particular sweet spot.
I agree with this.
Curlies or Lisp-like curves play a ton nicer with tooling and visual inspection.
It's an ambiguity problem similar to the dangling else. There's no way to automatically tell the editor that I want the statements to go here or there.
edit: Yes, there's a reformat command in emacs. No, it does not work correctly for Python, because the lack of delimiters means it does not have the information it needs to do the job right.
If it were an actual grammatical ambiguity, any editor couldn't get it right but it can't be since the Python parser can understand it.
Here's a pastebin that illuminates the problem.
http://pastebin.com/3fdxts4n
edit: What version of emacs are you using? Are you using python.el or python-mode.el for editing Python? python.el handles try/except, if/else, etc., etc., indentation pretty marvelously.
edit2: If you'd rather talk about this out-of-band I'm on freenode as mdeboard or my email address is in my profile.
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..
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.
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.
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.
is clearly not preferable to 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/
[2]: http://www.python.org/dev/peps/pep-0257/#handling-docstring-...
Which is a silly reason. Why not add other things from other languages all to keep 'consistant'?