Python and Ruby
in [Python]
|
From: rantingrick on 31 Jan 2010 06:01 On Jan 30, 10:43 am, Nobody <nob...(a)nowhere.com> wrote: > That's also true for most functional languages, e.g. Haskell and ML, as > well as e.g. Tcl and most shells. Why require "f(x)" or "(f x)" if "f x" > will suffice? yuck! wrapping the arg list with parenthesis (python way) makes the most sense. Its to easy to misread somthing like this onetwothree four five six onetwothree(four, five, six) #ahhh... plain english.
From: Steven D'Aprano on 31 Jan 2010 06:35 On Sun, 31 Jan 2010 03:01:51 -0800, rantingrick wrote: > On Jan 30, 10:43 am, Nobody <nob...(a)nowhere.com> wrote: > >> That's also true for most functional languages, e.g. Haskell and ML, as >> well as e.g. Tcl and most shells. Why require "f(x)" or "(f x)" if "f >> x" will suffice? > > yuck! wrapping the arg list with parenthesis (python way) makes the most > sense. Its to easy to misread somthing like this > > onetwothree four five six > > onetwothree(four, five, six) #ahhh... plain english. I think the readability factor is mostly down to what you're familiar with. But consistency is also important: in Python, you always refer to an object the same way. Given an object called x, you ALWAYS refer to the object itself as x. In languages that don't use parentheses, x refers to the object, unless the object is a function, in which case x refers to the result of calling the object with no arguments. Other languages need special syntax to get access to the function object itself. Because it's hard to do, people don't do it often. But in Python, getting the function object is easy, and so treating functions as first- class objects is easy. -- Steven
From: Nobody on 31 Jan 2010 15:14 On Sat, 30 Jan 2010 16:58:34 +0000, tanix wrote: >>I'm not familiar with Ruby, but most languages are cleaner than Python >>once you get beyond the "10-minute introduction" stage. > > I'd have to agree. The only ones that beat Python in that department are > Javascript and PHP. Plus CSS and HTML if you can call those languages. > > The very idea of using a number of blanks to identify your block level is > as insane as it gets. I don't have a problem with layout (indentation level as a syntax element). > First of all, combinations of blanks and tabs, > depending on how your ide is setup to expand tabs, may get you bugs, you'd > never imagine in your wild dreams. If you IDE places tab stops other than every 8 columns, it's broken. Configurable tab stops in a text editor is one of those "features" that differentiates a "coder" from a software engineer. A coder implements it because it's easy to implement, without giving a moment's thought to the wider context (such as: how to communicate the non-standard tab stops to any other program which needs to read the file). Even so, it's quite simple to implement layout in a way which doesn't care about tab widths: 1. If the current line begins with exactly the same sequence of whitespace characters as the last non-blank line, it's part of the same block. 2. If the sequence of whitespace characters at the beginning of the current line is an extension of that for the last non-blank line (i.e. it starts with the previous sequence, then adds some more whitespace), then it's the first line of a inner block. 3. If the current line begins with a left substring of the sequence for the last non-blank line, then it belongs to an outer block (whichever one has that sequence). 4. If none of the above are true, it's a syntax error. > Braces is the most reliable way to identify blocks. No they aren't. Indentation is much easier for humans to process than scanning the file for braces (and not missing any). If you have any indentation in the code, humans will interpret it as indicating the nesting, even if the compiler doesn't. E.g.: if(x) { if(y) foo(); else bar(); } See the problem? The compiler will match the else with if(y), but a human will tend to match it with if(x). Layout ensures that a human sees what the compiler "sees". Given that any sane program uses indentation to reflect the program's structure, braces (or "begin", or "end" (or endif/endwhile/etc)) are redundant.
From: Nobody on 31 Jan 2010 15:43 On Sun, 31 Jan 2010 03:01:51 -0800, rantingrick wrote: >> That's also true for most functional languages, e.g. Haskell and ML, as >> well as e.g. Tcl and most shells. Why require "f(x)" or "(f x)" if "f x" >> will suffice? > > yuck! wrapping the arg list with parenthesis (python way) makes the most > sense. Its to easy to misread somthing like this > > onetwothree four five six > > onetwothree(four, five, six) #ahhh... plain english. Note: Functional languages allow: f (a,b,c) but that means something else, i.e. calling a function with a tuple as its argument (in functional languages, a function always has exactly one argument). The syntax: f a b c is equivalent to the Python expression: f(a)(b)(c) i.e. each argument is applied in turn, with all applications except the last yielding a function. Defining f as: f a b c = <expression> is shorthand for: f = \a -> (\b -> (\c -> <expression>)) or, in Python syntax: f = lambda a: (lambda b: (lambda c: <expression>)) This style (known as Currying, or a Curried function, after the mathematician Haskell Curry) is common in functional languages, as it allows you to partially apply functions, e.g.: map (f a b) someList whereas an uncurried function would require a lambda expression: map (\c -> f (a,b,c)) someList IOW, while the uncurried form is allowed, it has no advantages and one disadvantage, so it's seldom used (and where it is used, it's normally a case of a function whose sole argument is a naturally-occurring tuple, rather than one which is constructed simply to satisfy the mechanics of a function call). Partial application is common enough that Haskell supports it for infix operators as well, e.g. map (/ 2) someList -- (/ 2) => \x -> x / 2, i.e. halve map (1 /) someList -- (1 /) => \x -> 1 / x, i.e. reciprocal If it was common-place to use Curried functions and partial application in Python, you'd probably prefer "f a b c" to "f(a)(b)(c)" as well.
From: John Bokma on 31 Jan 2010 15:47
Nobody <nobody(a)nowhere.com> writes: > Configurable tab stops in a text editor is one of those "features" that > differentiates a "coder" from a software engineer. A coder implements it > because it's easy to implement, without giving a moment's thought to the > wider context (such as: how to communicate the non-standard tab stops to > any other program which needs to read the file). [..] > if(x) { > if(y) > foo(); > else > bar(); > } > > See the problem? Nope, because a good editor will format this correctly. One written by software engineers ;-) > Given that any sane program uses indentation to reflect the program's > structure, braces (or "begin", or "end" (or endif/endwhile/etc)) are > redundant. 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. FWIW: I have no problem with how Python doesn't use braces nor on how other languages do insist on braces or other structure markers. -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development |