5 ms·
Python-Dev: Adding braces to __future__
- exDM69 15y agoThe 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.
- philh 15y agoThe 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. I agree with this.
- syaz1 15y agoI think that was sarcasm because OP posted it in -patch instead of -ideas list.
- meepmorp 15y agoJesus Christ on a crutch, just set up your goddamn editor to replace tabs with spaces and get on with life. People who find this problematic need to find another language or stop focusing on trivia.
- BerislavLopac 15y ago"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. :)
- aGHz 15y agoNo joke! This is what happens when trolls are classically trained.
- exDM69 15y ago>> 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.
- obtu 15y agoThere'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.
- exDM69 15y agoSimplicity 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.
- yuvadam 15y agotl;dr; - troll posts long rant on why Python should do delimited blocks in addition to whitespace blocks, devs tell troll to take a hike.
- syaz1 15y agoI'm curious what is your definition of troll.
- pnathan 15y agoWhitespace 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.
- mattdeboard 15y agoSounds like a problem with your choice of editor, not Python. Try emacs or vim.
- pnathan 15y agoI use emacs. 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.
- rmc 15y agoIn Vim, just select the text (with V), then use < or > to deinter or indent resp.
- decklin 15y agoThat's what he meant by "manually".
- exDM69 15y agoDo 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.
- phzbOx 15y agoWhat 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 agoYep, 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 agoI'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 agoI 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.
- rmc 15y agoThe main (and only?) argument this poster gives for adding braces is consistency with other languages. Which is a silly reason. Why not add other things from other languages all to keep 'consistant'?
- kibwen 15y agoGuido'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)