

Python-Dev: Adding braces to __future__ - jashkenas
http://mail.python.org/pipermail/python-dev/2011-December/114859.html

======
kibwen
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)

------
phzbOx
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
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
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.

------
BerislavLopac
"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. :)

~~~
exDM69
>> 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
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.

~~~
exDM69
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.

~~~
obtu
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.

~~~
exDM69
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.

------
meepmorp
Jesus 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.

------
yuvadam
_tl;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
I'm curious what is _your_ definition of troll.

------
rmc
The 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'?

------
pnathan
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.

~~~
mattdeboard
Sounds like a problem with your choice of editor, not Python. Try emacs or
vim.

~~~
pnathan
I 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.

~~~
exDM69
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.

~~~
pnathan
It is not a grammatical ambiguity in terms of Python.

Here's a pastebin that illuminates the problem.

<http://pastebin.com/3fdxts4n>

~~~
mattdeboard
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.

~~~
pnathan
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...

~~~
mattdeboard
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.

------
exDM69
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.

~~~
philh
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.

I agree with this.

~~~
syaz1
I think that was sarcasm because OP posted it in -patch instead of -ideas
list.

