Python and Ruby
in [Python]
|
From: Chris Rebert on 31 Jan 2010 20:33 On Sun, Jan 31, 2010 at 5:22 PM, Steven D'Aprano <steven(a)remove.this.cybersource.com.au> wrote: > 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? Make the state explicit, i.e. monads or uniqueness typing. In the case of random(), you have it take the seed explicitly as an argument and have it return a new seed along with the "randomly" generated number. In the case of time(), you pass around an argument to represent the state of the outside world. I don't quite grok monads, but http://en.wikipedia.org/wiki/Uniqueness_type has a decent example of the general uniqueness type approach. Cheers, Chris -- http://blog.rebertia.com
From: John Bokma on 31 Jan 2010 22:30 Steven D'Aprano <steven(a)REMOVE.THIS.cybersource.com.au> writes: > 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, Yes it can. I *have* seen Python with broken indentation on web pages, and good luck sorting it out. Blaming it on "broken tools" is just another straw man. It happens, and if you're learning Python and interested in that code you have a problem. Snipped the rest, because you start to sound like a zealot. I should've know better. -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development
From: Steven D'Aprano on 1 Feb 2010 01:17 On Sun, 31 Jan 2010 18:53:16 -0600, John Bokma wrote: > You don't have to buy my argument, I am not selling it. It's a figure of speech. You are making an argument others have made before, and I don't accept the validity of the argument. -- Steven
From: Paul Rubin on 1 Feb 2010 01:22 Steven D'Aprano <steven(a)REMOVE.THIS.cybersource.com.au> writes: > How would Haskell coders write it? Something like this? > > def get_popular_name(url): > data = fetch url > names = parse data > name = choose name 1 > return name The syntax and types would be different, but ok, something like that. > name = get_popular_name 'http://guessmyname.com' # call the function > f = decorate get_popular_name # treat the function as a 1st class object You wouldn't need "decorate". You'd just say f = get_popular_name "http://guessmyname.com" f is now an "I/O action" which when executed queries the guessmyname site. > but now how do I call the new function? > Is this where you say "Monads" and everyone's eyes glaze over? You'd say something like most_popular_name <- f to invoke the action. Yes, explaining the difference between "<-" and "=" involves monads. You might like the Haskell tutorial http://learnyouahaskell.com .
From: Steven D'Aprano on 1 Feb 2010 01:27
On Sun, 31 Jan 2010 21:30:15 -0600, John Bokma wrote: >>>>> 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, > > Yes it can. I *have* seen Python with broken indentation on web pages, > and good luck sorting it out. Blaming it on "broken tools" is just > another straw man. You're using that term wrong. It looks to me that you don't actually know what a straw man argument is. A straw man argument is when somebody responds to a deliberately weakened or invalid argument as if it had been made by their opponent. You raised the issue that the redundancy which prettyfiers exploit are a good reason for preferring braces, so it's not a straw man argument. It's not a straw man to say that you don't need a code prettyfier if indentation is significant when you raised the issue of prettyfiers in the first place. I certainly accept that braces + indentation do provide redundancy, and if the norm was noisy channels, that redundancy would be valuable. But that's not the norm. Most channels don't delete leading whitespace, and those noisy channels we do deal with (like web forms) tend to introduce far more noise than merely deleting leading whitespace, e.g. word- wrapping long lines. The argument that "web pages break indentation, therefore braces are better" is a real argument that some people make, but it is very weak. Suppose there was a web page that arbitrarily deleted braces out of some misplaced sense of security. Would anyone argue that this proves that indentation was better and braces were bad? No, of course not -- they would say "That website is broken". > It happens, and if you're learning Python and > interested in that code you have a problem. Yes you do. If you're trying to learn carpentry, and somebody gives you a blunt saw that causes the wood to break rather than cut cleanly, you have a problem. If you're learning to cook, and they give you a put with a hole in it and tell you to make soup in it, you have a problem. Broken tools lead to problems. > Snipped the rest, because you start to sound like a zealot. I should've > know better. Yeah, whatever. -- Steven |