Python and Ruby
in [Python]
|
From: John Bokma on 31 Jan 2010 19:47 Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> writes: > On Sun, 31 Jan 2010 14:47:08 -0600, John Bokma wrote: > >> An editor can correct the indenting of the braces example but can't with >> this one. >> >> if x: >> if y: >> foo() >> else: >> bar() >> >> While braces might be considered redundant they are not when for one >> reason or another formatting is lost or done incorrectly. > > I've heard this argument before, and I don't buy it. Why should we expect > the editor to correct malformed code? Or a prettyfier. It doesn't matter. The point is that with braces there *is* redundancy that be used to fix the code. > Would you expect your editor to correct this malformed code? > > result = sin(x+)y Nice straw man. Let me repeat again: I am ok with how Python works. To be honest I think it's cleaner compared to using {}. But in there are real life examples in which Python code will break where code with braces will survive. -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development
From: Chris Rebert on 31 Jan 2010 19:50 On Sun, Jan 31, 2010 at 4:25 PM, Steven D'Aprano <steven(a)remove.this.cybersource.com.au> wrote: > On Sun, 31 Jan 2010 15:40:36 -0800, Chris Rebert wrote: >> On Sun, Jan 31, 2010 at 2:36 PM, Steven D'Aprano >> <steve(a)remove-this-cybersource.com.au> wrote: >>> On Sun, 31 Jan 2010 04:28:41 -0800, Ed Keith wrote: >>>> In most functional languages you just name a function to access it and >>>> you do it ALL the time. >>>> >>>> for example, in if you have a function 'f' which takes two parameters >>>> to call the function and get the result you use: >>>> >>>> Â f 2 3 >>>> >>>> If you want the function itself you use: >>>> >>>> Â Â f >>> >>> How do you call a function of no arguments? >> >> It's not really a function in that case, it's just a named constant. >> (Recall that functions don't/can't have side-effects.) > > >>>> time.time(), random.random() > (1264983502.7505889, 0.29974255140479633) >>>> time.time(), random.random() > (1264983505.9283719, 0.74207867411026329) > > > They don't look terribly constant to me. Those aren't functions in the pure functional programming sense; which is unsurprising since Python isn't a [pure] functional language. They both involve side-effects. time() does I/O to the clock chip to see what time it is, and random() uses and changes a global seed value variable (which, in a double-whammy, takes its initial value from time()). Pure functions must be referentially transparent [http://en.wikipedia.org/wiki/Referential_transparency_(computer_science)], and as you've demonstrated, neither of those Python functions qualify. Cheers, Chris -- http://blog.rebertia.com
From: John Bokma on 31 Jan 2010 19:53 Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> writes: > On Sun, 31 Jan 2010 14:47:08 -0600, John Bokma wrote: > >> An editor can correct the indenting of the braces example but can't with >> this one. >> >> if x: >> if y: >> foo() >> else: >> bar() >> >> While braces might be considered redundant they are not when for one >> reason or another formatting is lost or done incorrectly. > > I've heard this argument before, and I don't buy it. Why should we expect > the editor to correct malformed code? I do expect my editor to assist me in coding. In Emacs I have to do some effort to enter the broken C code in the earlier post, and when I reformat the code, it will be lined out correctly. I can't do that with the above example, because it's correctly formatted. You don't have to buy my argument, I am not selling it. While in the past I wrote that an editor can't make you that more productive I want to take that back, on the record. Since I've switched to Emacs the editor has saved me several times from minor issues. Either because it refused to indent correctly thanks to a missing closing }, ), ] or other error. With the correct mode in Emacs one gets, in my experience, immediate feedback when making mistakes one otherwise find during the run/compiling phase. Note that I am also not selling Emacs. It's free after all. -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development
From: Steven D'Aprano on 31 Jan 2010 20:22 On Sun, 31 Jan 2010 16:50:50 -0800, Chris Rebert wrote: >>>> How do you call a function of no arguments? >>> >>> It's not really a function in that case, it's just a named constant. >>> (Recall that functions don't/can't have side-effects.) >> >> >>>>> time.time(), random.random() >> (1264983502.7505889, 0.29974255140479633) >>>>> time.time(), random.random() >> (1264983505.9283719, 0.74207867411026329) >> >> >> They don't look terribly constant to me. > > Those aren't functions in the pure functional programming sense; which > is unsurprising since Python isn't a [pure] functional language. They > both involve side-effects. time() does I/O to the clock chip to see what > time it is, and random() uses and changes a global seed value variable > (which, in a double-whammy, takes its initial value from time()). Yes, but these tasks -- get the time, get a (pseudo) random number -- are not unique to Python. Surely even Lisp and Haskell code will sometimes need to know the time. Whether they are "pure functions" (functions in the mathematical sense) or impure, they're still functions in some sense. How do you deal with such impure functions? -- Steven
From: Steven D'Aprano on 31 Jan 2010 20:33
On Sun, 31 Jan 2010 18:47:42 -0600, John Bokma wrote: > Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> writes: > >> On Sun, 31 Jan 2010 14:47:08 -0600, John Bokma wrote: >> >>> An editor can correct the indenting of the braces example but can't >>> with this one. >>> >>> if x: >>> if y: >>> foo() >>> else: >>> bar() >>> >>> While braces might be considered redundant they are not when for one >>> reason or another formatting is lost or done incorrectly. >> >> I've heard this argument before, and I don't buy it. Why should we >> expect the editor to correct malformed code? > > Or a prettyfier. It doesn't matter. The point is that with braces there > *is* redundancy that be used to fix the code. Prettyfiers are significant in languages that allow braces (or begin/end tokens) and indentation to go out of sync. Since that can't happen with Python, it's not a problem that needs solving. Prettyfiers exist to work around a limitation of languages where indentation is not significant. Arguing that an advantage of braces is that prettyfiers can work with them easily is a silly argument. That's like saying an advantage of horse- drawn buggies over cars is that it will go faster when you hit the horse with a whip. That's true, but you only need the whip because of the lack of accelerator pedal. A much better argument would be that an advantage of significant indentation is that you no longer need a prettyfier, and a second advantage is a major reduction in flame wars over coding styles. >> Would you expect your editor to correct this malformed code? >> >> result = sin(x+)y > > Nice straw man. It's not a straw man. It's a serious argument. There is an infinite number of problems with malformed code that your editor can't fix, and your prettifier can't deal with. Why should we care if indentation is one more? There are tools out there (such as some web forum software) that corrupt whitespace. Those tools are broken, and if you (generic you), as a developer, are relying on those tools to code with, then shame on you. And if you're the creator of such broken tools, then shame on you more. You wouldn't arbitrarily decide to remove leading "E"s from the user's text, or trailing full stops, so why do you arbitrarily remove whitespace? > Let me repeat again: I am ok with how Python works. To be honest I think > it's cleaner compared to using {}. But in there are real life examples > in which Python code will break where code with braces will survive. Yes. So what? They are rare and insignificant in practice. For every line of code that you get via a webforum that mangles indentation, you get ten thousand lines of code from some place that doesn't. So long as code is written by and for human beings, the benefit of significant indentation is 100% practical, and the practical benefit of braces will remain insignificant. -- Steven |