Re: Tabs v.s. spaces
Darren Salt [EMAIL PROTECTED] wrote: I find myself wondering if Duff's Device is implementable in Python... The closest beast I can think of would generate the unrolled loop at runtime and use 'exec' to run it. But this is a bit off topic for d-d. -- Florent
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 09:58:54PM -0800, Steve Lamb wrote: | Cameron Patrick wrote: | I don't think it is. Python doesn't have a switch/case equivalent. It'd | have to be done with a bunch of if's or something. | | Well, depends. Do you consider its dictionary to be a switch? Nope, no fall-through in that one, so it doesn't help. It /is/ nifty though :-) Cameron.
Re: Tabs v.s. spaces
Cameron Patrick wrote: Nope, no fall-through in that one, so it doesn't help. It /is/ nifty though :-) Uh, there was a fall through there. Notice that if x has a value that isn't in the dictionary the if will fall through to the else. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpM33yGILlrf.pgp Description: PGP signature
Re: Tabs v.s. spaces
(This is waaay off-topic but what the heck, I'll keep going...)
On Wed, Nov 19, 2003 at 08:08:51AM -0800, Steve Lamb wrote:
| Cameron Patrick wrote:
| Nope, no fall-through in that one, so it doesn't help. It /is/ nifty
| though :-)
|
| Uh, there was a fall through there. Notice that if x has a value that
| isn't in the dictionary the if will fall through to the else.
I meant fall through in the sense that
switch(foo) {
case 1:
blah(); /* no break; */
case 2:
blurgh();
}
will run blurgh() if foo==1 or foo==2.
The original poster was talking about Duff's device:
http://www.lysator.liu.se/c/duffs-device.html
which relies on this (and other foul properties of C's switch/case) to
unroll a loop.
Cameron.
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 11:08:44PM -0600, Gunnar Wolf wrote: H. S. Teoh dijo [Mon, Nov 17, 2003 at 08:47:27PM -0500]: *chalks up one more reason to avoid Python like the plague...* Uh, care to rewrite that since Python is now on 2.3 and 1.5.2 is several years old? [snip] That doesn't negate the fact that I find significant whitespace rather atrocious. I really rather use a language where I'm free to format the code the way I want it, to maximally convey its meaning, rather than to be forced to write it a certain way because some genius decided that whitespace should be significant. I think you should really take a look at the Whitespace programming language [1], it will make you love Python. Oh, right. I hate foo, because it does bar Hey, there's also baz, which does a hell of a lot more of bar, therefore foo must be great Giving an example of something which is worse than the original doesn't mean the original suddenly is less of a headache. Fact is, Python uses the concept of significant whitespace, which a lot of us simply don't like. That's a personal opinion, and in most cases probably not a rational thing, so providing arguments won't help. Can we cut this thread here, please? (yeah, I know I started it) -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 09:46:15AM +0800, Isaac To wrote: Tom == Tom [EMAIL PROTECTED] writes: Tom Significant whitespace? Shudder, that brings back crusty old Tom memories of Fortran. I have great fondness for fortran because of Tom the wonderful mathematical algorithms in LinPack, but I have no Tom fondness for significant whitespace. Please actually try to code something in Python before commenting on its use of spaces. It is unlike the times of Fortran: in Fortran spaces are used to make programs easy to read by machines; in Python spaces are used to make programs easy to read by human. then why are they significant? -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 09:10:53AM +0100, Wouter Verhelst wrote: | Please actually try to code something in Python before commenting on its use | of spaces. It is unlike the times of Fortran: in Fortran spaces are used to | make programs easy to read by machines; in Python spaces are used to make | programs easy to read by human. | | then why are they significant? So that anything that attempts to parse the program, be it human or Python, can tell when nested blocks begin and end? FWIW it seems that most people who have actually /used/ Python quite like the significant whitespace thing, even if the idea makes them a bit squeamish at first. Cameron.
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 04:33:16PM +0800, Cameron Patrick wrote: On Tue, Nov 18, 2003 at 09:10:53AM +0100, Wouter Verhelst wrote: | Please actually try to code something in Python before commenting on its use | of spaces. It is unlike the times of Fortran: in Fortran spaces are used to | make programs easy to read by machines; in Python spaces are used to make | programs easy to read by human. | | then why are they significant? So that anything that attempts to parse the program, be it human or Python, can tell when nested blocks begin and end? FWIW it seems that most people who have actually /used/ Python quite like the significant whitespace thing, even if the idea makes them a bit squeamish at first. It's OT but I can't resist one more post: Now that I've seen the code it's obviously semantically identical to braces and semicolons -- so I'd have no problem with them. I've been looking for good MSAccess-ish app in Linux; now that Rekall is GPL I'll be learning Python. It does seem VB-ish in its emphasis on simplicity (and especially the no-semicolons thing); minus VB's block-closing statements. I basically have no problems with it.
Re: Tabs v.s. spaces
Wouter == Wouter Verhelst [EMAIL PROTECTED] writes: Tom Significant whitespace? Shudder, that brings back crusty old Tom memories of Fortran. I have great fondness for fortran because of Tom the wonderful mathematical algorithms in LinPack, but I have no Tom fondness for significant whitespace. Please actually try to code something in Python before commenting on its use of spaces. It is unlike the times of Fortran: in Fortran spaces are used to make programs easy to read by machines; in Python spaces are used to make programs easy to read by human. Wouter then why are they significant? If you mean literally, the answer is because the creator of the language decided that spaces should be significant. But you really mean why people want them to be significant, or why people will use this language if it is significant, the answer is because human beings treat whitespace as significant. I mean it. How many C programming books will warn you against writing code like the following? if (x != 0) printf(No problem, proceeding); myvar /= x; Human beings think that spaces are significant, and indeed more significant than braces, as illustrated in the example above. So Python simply reflects the significance of whitespace in human being, and use it in exactly that context: to group statements into blocks. Regards, Isaac.
RE: Tabs v.s. spaces (was Re: Programming first steps.)
Steve Lamb wrote: 2: Can you provide an example of such free-style coding that you speak so highly of? # Split header into separate header lines, dropping any unneeded or # spurious header lines: @header_lines = grep( ( /^(?: # Wanted headers: X-Spam-Status ):/ix or !/^(?: # Unwanted headers: Delivered-To| Path| Priority| Received| Return-Path | (?: # Prefixes: List| X )-[\w-]+ ):/ix ), split(/\n(?!\s)/, $header_unwrapped) ); I call that readable, but I guess somebody won't. ;-)
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Tue, Nov 18, 2003 at 11:55:01AM +0100, Julian Mehnle wrote: | Steve Lamb wrote: | 2: Can you provide an example of such free-style coding that you speak | so highly of? | | # Split header into separate header lines, dropping any unneeded or | # spurious header lines: | @header_lines = grep( | ( | /^(?: | # Wanted headers: | X-Spam-Status | ):/ix or | !/^(?: | # Unwanted headers: | Delivered-To| | Path| | Priority| | Received| | Return-Path | | (?: # Prefixes: | List| | X | )-[\w-]+ | ):/ix | ), | split(/\n(?!\s)/, $header_unwrapped) | ); | | I call that readable, but I guess somebody won't. ;-) I can more-or-less follow it and I don't speak Perl. :-) Python's parser wouldn't object to that, BTW, because it's all one expression - the following, for instance, is legal (although ugly) Python: if ( 1 + 1 == 2 ): print hi Cameron. PS. I'll try to stop posting in this thread now. Really
Re: Tabs v.s. spaces
On Mon, Nov 17, 2003 at 07:57:46PM -0800, Joshua Kwan wrote: Hear, hear. Yes, 8-space indentation is a matter of pressing the Tab key, but it's a bit too big.. I've always stuck with two spaces. So set your tabstop (and shiftwidth) in vi to 4, and you'll have four character indents. Or 2. And if you save the tabs in the files (ie don't use expandtab), then whoever else opens your code will get their preference and everybody is happy. Note that if you want to quickly format your code with tab-character indentation (== 8 spaces), I like astyle -t file. Works like a charm. I've only tried it with C/C++ code so I don't know whether it works for other kinds of files. VIM can do autoindenting for some languages too. Works OK with Perl, and C, and badly with Tcl (but doesn't everything?). Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 06:02:40PM -0800, Tom wrote: If whitespace mistakes are always caught at compile-time, then I probably wouldn't care about them either. So I'm not bashing python; having never used it: I'm bashing languages where syntatic mistakes are not caught at compile-time. I have no idea if Python is in that category or not. Python does catch inconsistent indenting at compile time. If you want to catch mixed tabs/spaces for block indenting, run python with -tt. As Stephen clarified earlier, Python uses significant indentation, not significant whitespace. Variables and objects are not defined by whitespace, the nested scope of logical blocks are. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpEOupM14RAx.pgp Description: PGP signature
Re: Tabs v.s. spaces
On Tue, 2003-11-18 at 01:46, Isaac To wrote: Tom == Tom [EMAIL PROTECTED] writes: Tom Significant whitespace? Shudder, that brings back crusty old Tom memories of Fortran. I have great fondness for fortran because of Tom the wonderful mathematical algorithms in LinPack, but I have no Tom fondness for significant whitespace. Please actually try to code something in Python before commenting on its use of spaces. It is unlike the times of Fortran: in Fortran spaces are used to make programs easy to read by machines; in Python spaces are used to make programs easy to read by human. You've never had to combine 'patch' and Python programs have you? After receiving a few created by people with different indent bigotries you quickly realise why significant whitespace is a fundamentally bad idea. I've had to go and ask someone where his new block was supposed to be indent-wise before because he used X-space tabs and only provided a single tab at the start. (And no, it wasn't in the obvious place.) (And this is ignoring the person who sent a patch made with -l that changed the indent level of a number of blocks.) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 11:45:52AM +0800, Cameron Patrick wrote: On Mon, Nov 17, 2003 at 08:56:49PM -0500, H. S. Teoh wrote: | Nevertheless, I find 8-space indentation too wasteful, 4-space | indentation too cumbersome to type, and 1-space indentation | unreadable. Your editor should do that for you! :-) If I can only find an editor that suits my taste... vi is Very Irritating, and emacs is an Extremely Massive And Cumbersome System. e.g. set softtabstop=4 in vim will allow you to have 4-character indentation by pressing the tab key and outdentation by pressing backspace, but the file will contain spaces instead of tabs. I would be surprised if other editors did not have a similar feature. Keep in mind that I can't stand vi and hate emacs, so I'm still using a very old (non-free!) editor. It's not exactly the greatest, but it irritates me the least. Personally I prefer 8-space indentation, though. [snip] I find that it is too restrictive, given that I insist on a 79-column limit on code lines. With 8-space indentation, you run out of nesting levels really fast, much faster than is possible to do non-trivial coding in. T -- The right half of the brain controls the left half of the body. This means that only left-handed people are in their right mind. -- Manoj Srivastava
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 11:34:14PM +1100, Hamish Moffatt wrote: On Mon, Nov 17, 2003 at 07:57:46PM -0800, Joshua Kwan wrote: Hear, hear. Yes, 8-space indentation is a matter of pressing the Tab key, but it's a bit too big.. I've always stuck with two spaces. So set your tabstop (and shiftwidth) in vi to 4, and you'll have four character indents. Or 2. If I can convince myself vi is usable beyond editing simple config files. ;-) And if you save the tabs in the files (ie don't use expandtab), then whoever else opens your code will get their preference and everybody is happy. I wouldn't be so quick to say that... for one, I line up my comments with tabs (8-space tabs), they would be misaligned with a different tab stop, and would look rather atrocious. Note that if you want to quickly format your code with tab-character indentation (== 8 spaces), I like astyle -t file. Works like a charm. I've only tried it with C/C++ code so I don't know whether it works for other kinds of files. VIM can do autoindenting for some languages too. Works OK with Perl, and C, and badly with Tcl (but doesn't everything?). [snip] Generally, I am skeptical of autoindenting tools. I usually do it by hand. (I don't buy the write-first-indent-later coding philosophy.) Also, my indenting style is complex enough to elude tools like 'indent'. I firmly believe in doing something right, right from the start. If something isn't properly indented when first written, it's broken and must be rewritten. T -- You've gotten under my skin. That you got there speaks ill of me. That you like it there speaks ill of you. -- Speek, K5
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 11:00:18AM -0500, H. S. Teoh wrote: VIM can do autoindenting for some languages too. Works OK with Perl, and C, and badly with Tcl (but doesn't everything?). [snip] Generally, I am skeptical of autoindenting tools. I usually do it by hand. (I don't buy the write-first-indent-later coding philosophy.) Also, my indenting style is complex enough to elude tools like 'indent'. I firmly believe in doing something right, right from the start. If something isn't properly indented when first written, it's broken and must be rewritten. Huh? Autoindenting happens while you're coding, not later. That's the whole point. (Of course, Vim can do it after, too, but that makes it a mini-indent(1), not autoindent.) -- Glenn Maynard
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 11:13:46AM -0500, Glenn Maynard wrote: On Tue, Nov 18, 2003 at 11:00:18AM -0500, H. S. Teoh wrote: VIM can do autoindenting for some languages too. Works OK with Perl, and C, and badly with Tcl (but doesn't everything?). [snip] Generally, I am skeptical of autoindenting tools. I usually do it by hand. (I don't buy the write-first-indent-later coding philosophy.) Also, my indenting style is complex enough to elude tools like 'indent'. I firmly believe in doing something right, right from the start. If something isn't properly indented when first written, it's broken and must be rewritten. Huh? Autoindenting happens while you're coding, not later. That's the whole point. [snip] Oh, you meant autoindenting as you type... I thought you were referring to indenting tools. As long as it's unintrusive, I'm OK with that. Unintrusive as in, not anywhere near the atrociousness of MS Word, for example. T -- Being able to learn is a great learning; being able to unlearn is a greater learning.
Re: Tabs v.s. spaces
Scott == Scott James Remnant [EMAIL PROTECTED] writes: Scott You've never had to combine 'patch' and Python programs have you? Scott After receiving a few created by people with different indent Scott bigotries you quickly realise why significant whitespace is a Scott fundamentally bad idea. If somebody send you Python code patch that does not use *your* indentation style that somebody has some serious problem. It's just like sending you a patch with all the variable names changed to ones that he prefers. I don't see why this should be a show stopper. But yes, there are other problems introduced by whitespace as block structure. E.g., it is more difficult to cut some code in one function and paste it into another. So for best results one really have to use an editor (and perhaps other tools) that knows about such significant whitespaces. Regards, Isaac.
Re: Tabs v.s. spaces
I swore that I wasn't going to get into the latest style war, but ... On Tue, Nov 18, 2003 at 10:55:38AM -0500, H. S. Teoh wrote: On Tue, Nov 18, 2003 at 11:45:52AM +0800, Cameron Patrick wrote: Personally I prefer 8-space indentation, though. I find that it is too restrictive, given that I insist on a 79-column limit on code lines. With 8-space indentation, you run out of nesting levels really fast, much faster than is possible to do non-trivial coding in. Does that make the kernel trivial? Just wondering. :) -- Colin Watson [EMAIL PROTECTED]
Re: Tabs v.s. spaces (was Re: Programming first steps.)
Julian Mehnle wrote: I call that readable, but I guess somebody won't. ;-) Actually it is quite readable and sensible in that it breaks down the regex into parts that a human can read. Oh, and the equivolant would be legal in Python. Which was kind of my point on asking H.S. the two questions I did in the order I did. I doubt he's touched Python so is unqualified to discuss what is and is not possible with its use of whitespace and was hoping to get an example from him and show that it is perfectly legal in Python. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpcN9opEtXIL.pgp Description: PGP signature
Re: Tabs v.s. spaces
H. S. Teoh [EMAIL PROTECTED] wrote: Oh, you meant autoindenting as you type... I thought you were referring to indenting tools. As long as it's unintrusive, I'm OK with that. Unintrusive as in, not anywhere near the atrociousness of MS Word, for example. Um, wasn't this thread about programming? A programmer should use a programmer's editor. A programmer's editor should be able to indent the code for the language used while it is being typed. If you are not able to use a programmer's editor, I fail to see how you can even try to argue about the usefulness of Python's whitespace handling. -- Florent
Re: Tabs v.s. spaces
Scott James Remnant [EMAIL PROTECTED] wrote: You've never had to combine 'patch' and Python programs have you? After receiving a few created by people with different indent bigotries you quickly realise why significant whitespace is a fundamentally bad idea. I've had to go and ask someone where his new block was supposed to be indent-wise before because he used X-space tabs and only provided a single tab at the start. (And no, it wasn't in the obvious place.) That is one reason why it is wise to stay at least 100 meters away from tabs whenever it is possible. -- Florent
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 06:04:54PM +0100, Florent Rougon wrote: If you are not able to use a programmer's editor, I fail to see how you can even try to argue about the usefulness of Python's whitespace handling. Yay! A whitespace flamewar! -- Glenn Maynard
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 12:26:37PM -0500, Glenn Maynard wrote: On Tue, Nov 18, 2003 at 06:04:54PM +0100, Florent Rougon wrote: If you are not able to use a programmer's editor, I fail to see how you can even try to argue about the usefulness of Python's whitespace handling. Yay! A whitespace flamewar! [snip] Yeah, 'whitespace' about sums up the value of it. Except to Python programmers, of course. :-P :-P T -- Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things. -- Doug Gwyn
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 04:41:34PM +, Colin Watson wrote: I swore that I wasn't going to get into the latest style war, but ... On Tue, Nov 18, 2003 at 10:55:38AM -0500, H. S. Teoh wrote: On Tue, Nov 18, 2003 at 11:45:52AM +0800, Cameron Patrick wrote: Personally I prefer 8-space indentation, though. I find that it is too restrictive, given that I insist on a 79-column limit on code lines. With 8-space indentation, you run out of nesting levels really fast, much faster than is possible to do non-trivial coding in. Does that make the kernel trivial? Just wondering. :) [snip] ObMicro$oft Yes. /ObMicro$oft ;-) T -- It is the quality rather than the quantity that matters. -- Lucius Annaeus Seneca
Re: Tabs v.s. spaces
Isaac To wrote: E.g., it is more difficult to cut some code in one function and paste it into another. So for best results one really have to use an editor (and perhaps other tools) that knows about such significant whitespaces. Not really if one is wanting to maintain proper indention in both cases all one needs is an editor which is able to add or subtract indention levels. I certainly have had no problems in my Python coding on moving code around that are at different levels. Mark the block, move it, reindent it a level or two and be done with it. *shrug* -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpPjq3sDEowe.pgp Description: PGP signature
Re: Tabs v.s. spaces (was Re: Programming first steps.)
I demand that Steve Lamb may or may not have written... [snip] if foo bar else baz fi gdr -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | Let's keep the pound sterling Experience is what you get when you don't get what you want.
Re: Tabs v.s. spaces
H. S. Teoh wrote: Yeah, 'whitespace' about sums up the value of it. Except to Python programmers, of course. :-P :-P Quite the contrary. First off generally flames are from the uninformed. Since in most cases the evils of whitespace are spouted off by those who have never once touched Python it is generally they who are flaming and not those who have actually used it. Secondly clearly they are deriving some worth from it. I mean you did post 12 messages to this thread. More than me, in fact. Finally I am still waiting for an answer to my two questions posed to you. 1: Have you ever used Python? 2: Provide an example of such free-style coding that you speak highly of. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpZ44SgipXaq.pgp Description: PGP signature
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 11:04:48AM -0800, Steve Lamb wrote: H. S. Teoh wrote: Yeah, 'whitespace' about sums up the value of it. Except to Python programmers, of course. :-P :-P Quite the contrary. First off generally flames are from the uninformed. Since in most cases the evils of whitespace are spouted off by those who have never once touched Python it is generally they who are flaming and not those who have actually used it. Secondly clearly they are deriving some worth from it. I mean you did post 12 messages to this thread. More than me, in fact. Finally I am still waiting for an answer to my two questions posed to you. 1: Have you ever used Python? 2: Provide an example of such free-style coding that you speak highly of. I have two serious examples and one light-hearted one: Serious #1: *It looks like multi-line method invocations require parenthesis to be indented at the paren level. Sometimes that's useful, but often I like to pack arguments tighter than that and indent only once on subsequent lines: myreallylongmethodname(bar, bar, bar, bar, bar, baz, baz, baz); myreallylongmethodname(bar, bar, bar, bar, bar, baz, baz, baz); Serious #2: Multiple statements per line in diagnostic code and error flow control. The operant value in both these cases is some code is relatively unimportant to the main flow of the program and doesn't warrant gobs of space. Real code should be indented like Python, but if everything is proper, important code gets lost in a bunch of scaffolding. Obiviously high equality code should be simple, but sometimes other values weigh slightly higher than writing perfect code, and flexibility is useful. Light-hearted: Sometimes I just feel like writing crappy multi-line, write-only code because it's not intended to change the world, and I want to see it all on the screen at once. Many real-world tasks are like this. No need to respond to these points, I can kind of predict the answers... -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+-
Re: Tabs v.s. spaces
Tom wrote: On Tue, Nov 18, 2003 at 11:04:48AM -0800, Steve Lamb wrote: *It looks like multi-line method invocations require parenthesis to be indented at the paren level. Sometimes that's useful, but often I like to pack arguments tighter than that and indent only once on subsequent lines: myreallylongmethodname(bar, bar, bar, bar, bar, baz, baz, baz); myreallylongmethodname(bar, bar, bar, bar, bar, baz, baz, baz); Nope. That was just my stylistic choice. The rule is that lines are continued within an opening brace and whitespace is ignored. So both the above are legit. Serious #2: Multiple statements per line in diagnostic code and error flow control. The operant value in both these cases is some code is relatively unimportant to the main flow of the program and doesn't warrant gobs of space. Actually, this I can see. Although I certianly don't miss it. Of course if you really want it... [EMAIL PROTECTED]:~} python Python 2.3+ (#2, Aug 10 2003, 11:33:47) [GCC 3.3.1 (Debian)] on linux2 Type help, copyright, credits or license for more information. print foo ; print bar foo bar ...you can have it. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpHjJNeIjBUG.pgp Description: PGP signature
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 11:04:48AM -0800, Steve Lamb wrote:
H. S. Teoh wrote:
Yeah, 'whitespace' about sums up the value of it. Except to Python
programmers, of course. :-P :-P
Quite the contrary. First off generally flames are from the
uninformed. Since in most cases the evils of whitespace are spouted off
by
those who have never once touched Python it is generally they who are
flaming and not those who have actually used it.
First off, note the smileys.
Secondly clearly they are deriving some worth from it. I mean you did
post 12 messages to this thread. More than me, in fact.
Secondly, note that I was merely expressing my personal preferences.
Finally I am still waiting for an answer to my two questions posed to
you.
1: Have you ever used Python?
Not for any non-trivial task, although I did try to learn it some time
ago. Recently, I had the chance to take another look at it; however, I
found Ruby, which seemed to have the best of both Perl and Python plus
true object-orientation. So when I move on from Perl (which I love, but
which admittedly has its flaws too), it will be to Ruby, not Python.
2: Provide an example of such free-style coding that you speak highly of.
[snip]
Example (Perl):
PARSE: {
m/\G (void|int|float) /gcx do { $type = $1 };
[EMAIL PROTECTED] /\*([^*]+|\*[^/])*\*\/@gcx next PARSE;
m/\G \s+ /gcx next PARSE;
m/\G \{ /gcx do {
my @statements = parse_block;
push @block, @statements;
};
}
OK, this example is a bit contrived (it doesn't really do anything
useful), but it illustrates one situation where you'd like to be able to
stick a block on a single line in one case (e.g., the first match) but
keep it as an indented block in another case (e.g. the last match).
More examples (C++):
try {
obj_handle handle = get_handle();
handle.write(data);
if (handle.error()) throw exception(obj_handle::write_error);
handle.verify(data);
if (handle.error()) throw exception(obj_handle::verify_error);
handle.commit();
if (handle.error()) {
commit_errors++;
if (retry_needed) {
retry_request();
}
}
}
Another contrived example, but shows the same principle: in most cases the
throw can remain on the same line to avoid code clutter, but when
something more involved is needed, you break it up into an indented block.
More Perl examples:
open FILE, $file1 or die Unable to open $file1: $!\n;
while (FILE) {
...
}
close FILE or die Error while reading $file1: $! ($?)\n;
open FILE, $file2 or do {
... # do something else
};
...
Again, the flexibility to use or not use indented blocks help greatly in
readability here.
Next example (C):
for (i=0; in; i++) {
struct iterator *it;
for (it=get_iter(data.values.list);
more_elements(it) value_of(it)!=search_value;
step(it));
if (value_of(it)==search_value) return 1;
}
Output example (C/C++):
if (debug==1)
printf(gettext(Debug dump:\n
Current registers: %s\n
Watch values: %s\n),
get_register_dump(),
get_watch_values());
Yes, this one is contrived, but you really *do* want the freedom to indent
in cases such as here in order to emphasize the nested function call.
Finally, constructors example (C++):
classA::classA(int x, int y) : xcoor(x), ycoor(y) {}
classB::classB(void (*)(int x, int y),
void classA::*callback(int i)) :
xcoor(x), ycoor(y), cb(callback) {
if (callback==NULL) throw exception();
}
Note how the flexibility to indent makes it possible to write simple
constructors on one line (classA), and layout complex constructors such as
in classB such that separate elements are clearly separated.
T
--
Right now I'm having amnesia and deja vu at the same time. I think I've
forgotten this before.
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 11:32:36AM -0800, Tom wrote: Serious #1: *It looks like multi-line method invocations require parenthesis to be indented at the paren level. Sometimes that's useful, but often I like to pack arguments tighter than that and indent only once on subsequent lines: myreallylongmethodname(bar, bar, bar, bar, bar, baz, baz, baz); myreallylongmethodname(bar, bar, bar, bar, bar, baz, baz, baz); No, this is not true. You are describing implicit line joining, which is described in the Library Reference[1] Section 2.1.3[2]. Expressions in parentheses, square brackets or curly braces can be split over more than one physical line without using backslashes... The indentation of the continuation lines is not important. Blank continuation lines are allowed. Besides, you don't NEED ';' in Python to end a single statement. Serious #2: Multiple statements per line in diagnostic code and error flow control. The operant value in both these cases is some code is relatively unimportant to the main flow of the program and doesn't warrant gobs of space. Real code should be indented like Python, but if everything is proper, important code gets lost in a bunch of scaffolding. Obiviously high equality code should be simple, but sometimes other values weigh slightly higher than writing perfect code, and flexibility is useful. You can combine statements (Compound Statements[3]) on a single line with the ';' character... print 'ERROR: You are mistaken'; sys.exit(1) Or control flow constructs... if test: if test2: print x Which could just as easily be written if test: if test2: print x Light-hearted: Sometimes I just feel like writing crappy multi-line, write-only code because it's not intended to change the world, and I want to see it all on the screen at once. Many real-world tasks are like this. yay. REFERENCES 1. http://www.python.org/doc/current/ref/ 2. http://www.python.org/doc/current/ref/implicit-joining.html 3. http://www.python.org/doc/current/ref/compound.html -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpSfe8N5dbhn.pgp Description: PGP signature
Re: Tabs v.s. spaces
H. S. Teoh wrote:
Not for any non-trivial task, although I did try to learn it some time
ago. Recently, I had the chance to take another look at it; however, I
found Ruby, which seemed to have the best of both Perl and Python plus
true object-orientation. So when I move on from Perl (which I love, but
which admittedly has its flaws too), it will be to Ruby, not Python.
Perl has good points? *shudder* I looked at Ruby and saw that it was
taking many of the bad points of Perl.
PARSE: {
m/\G (void|int|float) /gcx do { $type = $1 };
[EMAIL PROTECTED] /\*([^*]+|\*[^/])*\*\/@gcx next PARSE;
m/\G \s+ /gcx next PARSE;
m/\G \{ /gcx do {
my @statements = parse_block;
push @block, @statements;
};
}
Possible.
try {
obj_handle handle = get_handle();
handle.write(data);
if (handle.error()) throw exception(obj_handle::write_error);
handle.verify(data);
if (handle.error()) throw exception(obj_handle::verify_error);
handle.commit();
if (handle.error()) {
commit_errors++;
if (retry_needed) {
retry_request();
}
}
}
Possible.
More Perl examples:
open FILE, $file1 or die Unable to open $file1: $!\n;
while (FILE) {
...
}
close FILE or die Error while reading $file1: $! ($?)\n;
open FILE, $file2 or do {
... # do something else
};
...
Possible.
Next example (C):
for (i=0; in; i++) {
struct iterator *it;
for (it=get_iter(data.values.list);
more_elements(it) value_of(it)!=search_value;
step(it));
if (value_of(it)==search_value) return 1;
}
Possible.
Output example (C/C++):
if (debug==1)
printf(gettext(Debug dump:\n
Current registers: %s\n
Watch values: %s\n),
get_register_dump(),
get_watch_values());
Possible.
Finally, constructors example (C++):
classA::classA(int x, int y) : xcoor(x), ycoor(y) {}
classB::classB(void (*)(int x, int y),
void classA::*callback(int i)) :
xcoor(x), ycoor(y), cb(callback) {
if (callback==NULL) throw exception();
}
Possible.
Note how the flexibility to indent makes it possible to write simple
constructors on one line (classA), and layout complex constructors such as
in classB such that separate elements are clearly separated.
So exactly where's your problem with the white space again? If you
really wanted to do each of those you could easily enough. Oddly enough in
each case you'll mostly be removing braces. I hope this concludes the topic
for those who haven't touched Python badmouthing the whitespace issue since,
thus far, I've yet to see a single example which isn't possible in pretty much
the exact same visual style.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
---+-
pgpLPaEZO7rLq.pgp
Description: PGP signature
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 08:07:35PM +, Jonathan Dowland wrote: Torvalds' position is that code that cannot be expressed using 8-spaces-per-indent and wrap at 79 characters needs to be rewritten. Who is Thorvalds? SCNR Balu /* vim: set expandtab tabstop=4 shiftwidth=4 softtabstop=4 nowrap: */
Re: Tabs v.s. spaces
I demand that Steve Lamb may or may not have written... [snip] I hope this concludes the topic for those who haven't touched Python badmouthing the whitespace issue since, thus far, I've yet to see a single example which isn't possible in pretty much the exact same visual style. I find myself wondering if Duff's Device is implementable in Python... -- | Darren Salt | nr. Ashington, | linux (or ds) at | woody, sarge, | Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | This space reserved for future expansion I can't reach the brakes on this piano!
Re: Tabs v.s. spaces
On Wed, Nov 19, 2003 at 01:19:32AM +, Darren Salt wrote: | I find myself wondering if Duff's Device is implementable in Python... I don't think it is. Python doesn't have a switch/case equivalent. It'd have to be done with a bunch of if's or something. Cameron.
Re: Tabs v.s. spaces
Cameron Patrick wrote:
I don't think it is. Python doesn't have a switch/case equivalent. It'd
have to be done with a bunch of if's or something.
Well, depends. Do you consider its dictionary to be a switch?
def foo():
... print foolio
...
def bar():
... print bario
...
baz = {'foo':foo, 'bar':bar}
for x in baz:
... if baz.has_key(x):
... baz[x]()
... else:
... print 'blorg'
...
foolio
bario
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
---+-
pgpU2NJzQN4Ce.pgp
Description: PGP signature
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 11:47:34AM -0600, Chad Walstrom wrote:
[snip]
I have a love-hate relationship with the significant whitespace.
I have a hate-hate relationship with it. I much prefer free-style syntax
where the programmer is allowed to use his best judgment on how to indent
the code. Of course, in less-than-ideal projects, or projects with
less-then-ideal programmers, this could result in a mess, but I'm speaking
of personal preference here.
I have always disliked 8 spaces per tab, because it takes up too much
screen real estate on an 80 column display. Whenever I coded in C, I
set my vi editor to interpret the tabs as 4 spaces. My mistake in using
this was displayed when I tried to print with a2ps or enscript, when
they were once again interpreted as 8 spaces. Arg!
I personally insist on 8 spaces per tab, because way too many things break
otherwise.
I then switched back to using only spaces for indentation, and this
seems to be a consistent approach, but because personal opinion in
coding style seems to be a right of passage amongst C coders, I could
never get anyone to agree with me. ;-) Even the venerable linux kernel
only accepts tabs, IIRC[1].
Actually, I do agree with you. I only use tabs for comments, or for
overly-long lines which needs to be broken, but which does not represent
syntactical nesting, eg:
void some_function_with_a_very_long_name(some_data_type *a,
some_other_data_type *b, ...) { ... }
For syntactical nesting, I use spaces alone, even if it means I have to
expend extra effort to hit the space bar. The reason I insist on this in
my own coding style is because tabs mixed with spaces in a single stretch
of whitespace are just Pure Evil(tm). They show up all wrong in a viewer
that has a different tab size, and do not behave consistently when you are
re-indenting lines (eg., if a line starts with tabtabspacecode,
and you insert spaces in front of it to indent it, the spaces just get
eaten by the tab; and if you are outdenting it, the deleted tab causes
it to outdent too far, but inserting more spaces doesn't compensate for it
because the second tab eats the spaces).
I use tabs for comments only for my own sanity's sake, since otherwise I'd
have to count 40 columns every time I want to comment a line of code.
Another problem. Try cut-n-paste in X between code that uses tabs[2].
Sometimes the tabs are not preserved. Very odd and annoying.
That's because the terminal settings are b0rked. I personally delete all
programs that cannot cut-n-paste without messing up tabs and spaces.
Unfortunately, this happens a lot on the Winbloxe desktop at work.
[snip]
So, tabs v.s. spaces isn't really a concern except when mixing the two.
If you use eight spaces for all indentation, it won't matter. If you
use some other number, it's best to use spaces exclusively. If you use
tabs exclusively, changing the appearance in your editor may simply be a
configuration option away. What will I use? I still haven't decided;
probably tabs/8 spaces. ;-p
[snip]
For personal pet projects, I use 2 spaces per nesting level. Some people
think that's Pure Evil(tm), although I fully agree with you about wasting
screen real estate in 80 columns (yes, I am one of those freaks who insist
that all code must not have lines longer than 79 characters).
Nevertheless, for their sake I use 4 spaces per nesting level in group
projects.
Also, as an off-topic note, blank lines that contain tabs or spaces are
Pure Evil(tm), especially in code. One of these days I should write a sed
script to eliminate all incarnations of this Pure Evil(tm) from /usr/src.
T
--
There are four kinds of lies: lies, damn lies, and statistics.
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 02:19:02PM -0500, H. S. Teoh wrote: For personal pet projects, I use 2 spaces per nesting level. Some people think that's Pure Evil(tm), Most noteably perhaps, Linus Torvalds, although... although I fully agree with you about wasting screen real estate in 80 columns (yes, I am one of those freaks who insist that all code must not have lines longer than 79 characters). ...he agrees with you on that point! Torvalds' position is that code that cannot be expressed using 8-spaces-per-indent and wrap at 79 characters needs to be rewritten. -- Jon Dowland http://jon.dowland.name/
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 02:19:02PM -0500, H. S. Teoh wrote: Also, as an off-topic note, blank lines that contain tabs or spaces are Pure Evil(tm), especially in code. One of these days I should write a sed script to eliminate all incarnations of this Pure Evil(tm) from /usr/src. Python did away with that requirement for scope in 2.x. If you want to use blank lines for code logic separation in python 2.0, you must nest the line as far as the current block. For that reason, I don't use blank lines within class or method definitions when writing for Python 1.5.x. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpoxeZnYjtzN.pgp Description: PGP signature
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 08:07:35PM +, Jonathan Dowland wrote: On Mon, Nov 17, 2003 at 02:19:02PM -0500, H. S. Teoh wrote: For personal pet projects, I use 2 spaces per nesting level. Some people think that's Pure Evil(tm), Most noteably perhaps, Linus Torvalds, although... although I fully agree with you about wasting screen real estate in 80 columns (yes, I am one of those freaks who insist that all code must not have lines longer than 79 characters). ...he agrees with you on that point! Torvalds' position is that code that cannot be expressed using 8-spaces-per-indent and wrap at 79 characters needs to be rewritten. [snip] That would mean 95% of non-trivial XSLT stylesheets would need to be rewritten... (Sorry, I'm just bitter after having to deal with non-trivial text-processing in XSLT. Don't try this at home without life insurance.) T -- Curiosity kills the cat. Moral: don't be the cat.
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 02:29:52PM -0600, Chad Walstrom wrote: On Mon, Nov 17, 2003 at 02:19:02PM -0500, H. S. Teoh wrote: Also, as an off-topic note, blank lines that contain tabs or spaces are Pure Evil(tm), especially in code. One of these days I should write a sed script to eliminate all incarnations of this Pure Evil(tm) from /usr/src. Python did away with that requirement for scope in 2.x. If you want to use blank lines for code logic separation in python 2.0, you must nest the line as far as the current block. For that reason, I don't use blank lines within class or method definitions when writing for Python 1.5.x. [snip] Hmm, I did not know this before. *chalks up one more reason to avoid Python like the plague...* T -- Leather is waterproof. Ever see a cow with an umbrella?
Re: Tabs v.s. spaces (was Re: Programming first steps.)
H. S. Teoh wrote: On Mon, Nov 17, 2003 at 02:29:52PM -0600, Chad Walstrom wrote: On Mon, Nov 17, 2003 at 02:19:02PM -0500, H. S. Teoh wrote: Also, as an off-topic note, blank lines that contain tabs or spaces are Pure Evil(tm), especially in code. One of these days I should write a sed script to eliminate all incarnations of this Pure Evil(tm) from /usr/src. Python did away with that requirement for scope in 2.x. If you want to use blank lines for code logic separation in python 2.0, you must nest the line as far as the current block. For that reason, I don't use blank lines within class or method definitions when writing for Python 1.5.x. [snip] Hmm, I did not know this before. *chalks up one more reason to avoid Python like the plague...* Uh, care to rewrite that since Python is now on 2.3 and 1.5.2 is several years old? -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpBn1DSwtMxV.pgp Description: PGP signature
Re: Tabs v.s. spaces (was Re: Programming first steps.)
H. S. Teoh wrote:
On Mon, Nov 17, 2003 at 11:47:34AM -0600, Chad Walstrom wrote:
[snip]
I have a love-hate relationship with the significant whitespace.
I have a hate-hate relationship with it. I much prefer free-style syntax
where the programmer is allowed to use his best judgment on how to indent
the code. Of course, in less-than-ideal projects, or projects with
less-then-ideal programmers, this could result in a mess, but I'm speaking
of personal preference here.
Problem is that in languages which allow free-style syntax you're not
allowed free-style syntax at all. You're required to match }'s with {'s (or
the local language equivolents) and end all lines with ; (except for some
cases when you don't have to). This is still a restriction of the same order,
just with different characters and rules.
Oddly enough ever since picking up Python a few years back I've never
once felt constrained by its significant whitespace. I felt a profound
relief, however, when dealing with other people's code becuase it looked and
behaved just like mine. There is enough freedom in the rules that a
programmer doesn't have to worry about the end of the screen yet there is
enough sensible structure to make the code readable. I mean, let's get down
to it
if foo {
bar;
} else {
baz;
}
if foo
{
bar;
}
else
{
baz;
}
if foo {
bar;
}
else {
baz;
}
if you remove the points of contention between those three you're left
with...
if foo
bar
else
baz
...which is a colon away from legal Python syntax. :P
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
---+-
pgpmr0ZaaMWcX.pgp
Description: PGP signature
Re: Tabs v.s. spaces
H == H S Teoh [EMAIL PROTECTED] writes: H That would mean 95% of non-trivial XSLT stylesheets would need to be H rewritten... Or perhaps the XSLT language itself needs to be rewritten. Regards, Isaac.
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 05:21:23PM -0800, Steve Lamb wrote:
H. S. Teoh wrote:
On Mon, Nov 17, 2003 at 11:47:34AM -0600, Chad Walstrom wrote:
[snip]
I have a love-hate relationship with the significant whitespace.
I have a hate-hate relationship with it. I much prefer free-style syntax
where the programmer is allowed to use his best judgment on how to indent
the code. Of course, in less-than-ideal projects, or projects with
less-then-ideal programmers, this could result in a mess, but I'm speaking
of personal preference here.
Problem is that in languages which allow free-style syntax you're not
allowed free-style syntax at all. You're required to match }'s with {'s
(or the local language equivolents) and end all lines with ; (except for
some cases when you don't have to). This is still a restriction of the
same order, just with different characters and rules.
Oddly enough ever since picking up Python a few years back I've never
once felt constrained by its significant whitespace. I felt a profound
Significant whitespace? Shudder, that brings back crusty old memories
of Fortran. I have great fondness for fortran because of the wonderful
mathematical algorithms in LinPack, but I have no fondness for
significant whitespace.
relief, however, when dealing with other people's code becuase it looked
and behaved just like mine. There is enough freedom in the rules that a
programmer doesn't have to worry about the end of the screen yet there is
enough sensible structure to make the code readable. I mean, let's get
down to it
if foo {
bar;
} else {
baz;
}
if foo
{
bar;
}
else
{
baz;
}
if foo {
bar;
}
else {
baz;
}
if you remove the points of contention between those three you're left
with...
if foo
bar
else
baz
...which is a colon away from legal Python syntax. :P
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of
souls.
---+-
[OT] Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 09:28:29AM +0800, Isaac To wrote: H == H S Teoh [EMAIL PROTECTED] writes: H That would mean 95% of non-trivial XSLT stylesheets would need to be H rewritten... Or perhaps the XSLT language itself needs to be rewritten. [snip] Yes, that was my hidden motive. :-P Personally, I think XSLT is crap, although XPath is kinda cool. Somebody should invent a functional equivalent of XSLT minus the idiotic verbosity, and keep XPath. But who am I kidding, the entire XML syntax is painfully verbose. It's a chore both to read and write. (Yeah, yeah, I've heard the argument that it's supposed to be read only by machines. So why are so many programmers still writing XSLT by hand? Plus, if you want machine readable, go binary...) insert off-topic rant here T -- Give me some fresh salted fish, please.
Re: Tabs v.s. spaces
H == H S Teoh [EMAIL PROTECTED] writes: H I have a hate-hate relationship with it. I much prefer free-style H syntax where the programmer is allowed to use his best judgment on H how to indent the code. Of course, in less-than-ideal projects, or H projects with less-then-ideal programmers, this could result in a H mess, but I'm speaking of personal preference here. I don't quite understand why people hate it so much. Python allow indentation to be done in any number of spaces and tabs, as long as they are consistent. And you can even mix them, as long as they are consistently mixed. I.e., it is perfectly okay if your first level indentation is a tab and your second level indentation is 2 spaces further than the first level indentation. And different functions can use different indentation style. It is only when the indentation is inconsistent within a single function when the 8-spaces = 1 tab rule come into play. If you are writing such code, it is time to change your habit (either in terms of typing or in terms of the editor you use) anyway. H That's because the terminal settings are b0rked. I personally delete H all programs that cannot cut-n-paste without messing up tabs and H spaces. Unfortunately, this happens a lot on the Winbloxe desktop at H work. Which terminal do you use that do not convert all the tabs into spaces? Personally I won't cut-and-paste from the terminal when programming. H For personal pet projects, I use 2 spaces per nesting level. Some H people think that's Pure Evil(tm), although I fully agree with you H about wasting screen real estate in 80 columns (yes, I am one of H those freaks who insist that all code must not have lines longer than H 79 characters). I believe Linus has a point here... 8 spaces per indentation level keeps you honest, since you can't put a whole crowd of things into a single function. On the evil side, I had seen people who insist on using 1 space per indentation level. Regards, Isaac.
Re: Tabs v.s. spaces
Tom == Tom [EMAIL PROTECTED] writes: Tom Significant whitespace? Shudder, that brings back crusty old Tom memories of Fortran. I have great fondness for fortran because of Tom the wonderful mathematical algorithms in LinPack, but I have no Tom fondness for significant whitespace. Please actually try to code something in Python before commenting on its use of spaces. It is unlike the times of Fortran: in Fortran spaces are used to make programs easy to read by machines; in Python spaces are used to make programs easy to read by human. Regards, Isaac.
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 05:14:04PM -0800, Steve Lamb wrote: H. S. Teoh wrote: On Mon, Nov 17, 2003 at 02:29:52PM -0600, Chad Walstrom wrote: [snip] Python did away with that requirement for scope in 2.x. If you want to use blank lines for code logic separation in python 2.0, you must nest the line as far as the current block. For that reason, I don't use blank lines within class or method definitions when writing for Python 1.5.x. [snip] Hmm, I did not know this before. *chalks up one more reason to avoid Python like the plague...* Uh, care to rewrite that since Python is now on 2.3 and 1.5.2 is several years old? [snip] That doesn't negate the fact that I find significant whitespace rather atrocious. I really rather use a language where I'm free to format the code the way I want it, to maximally convey its meaning, rather than to be forced to write it a certain way because some genius decided that whitespace should be significant. T -- Designer clothes: how to cover less by paying more.
Re: Tabs v.s. spaces (was Re: Programming first steps.)
Tom wrote: Significant whitespace? Shudder, that brings back crusty old memories of Fortran. I have great fondness for fortran because of the wonderful mathematical algorithms in LinPack, but I have no fondness for significant whitespace. And? Does Fortran's rules map to Pythons? I often find that people who grouse about the whitespace are people who have never touched Python. Myself included before I touched Python. I can say this. I spent more time grousing about it in a few months than it has ever impacted my coding style in the years since. Have you touched Python? -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgplgG7NaC1N1.pgp Description: PGP signature
Re: Tabs v.s. spaces (was Re: Programming first steps.)
H. S. Teoh wrote: That doesn't negate the fact that I find significant whitespace rather atrocious. I really rather use a language where I'm free to format the code the way I want it, to maximally convey its meaning, rather than to be forced to write it a certain way because some genius decided that whitespace should be significant. Two questions. 1: Have you ever programmed in Python? 2: Can you provide an example of such free-style coding that you speak so highly of? -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgp2ZZrcJAqr8.pgp Description: PGP signature
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 09:43:40AM +0800, Isaac To wrote: [snip] H That's because the terminal settings are b0rked. I personally delete H all programs that cannot cut-n-paste without messing up tabs and H spaces. Unfortunately, this happens a lot on the Winbloxe desktop at H work. Which terminal do you use that do not convert all the tabs into spaces? Personally I won't cut-and-paste from the terminal when programming. Hmm, you're right. I just tested it from xterm, and it doesn't work quite the way I thought it did. I'm pretty sure xterm used to let you copy tabs properly, but that might be a very old version way back when. (Or perhaps just my imagination.) H For personal pet projects, I use 2 spaces per nesting level. Some H people think that's Pure Evil(tm), although I fully agree with you H about wasting screen real estate in 80 columns (yes, I am one of H those freaks who insist that all code must not have lines longer than H 79 characters). I believe Linus has a point here... 8 spaces per indentation level keeps you honest, since you can't put a whole crowd of things into a single function. Well, that's a whole 'nother can of worms. I firmly believe that all functions longer than one printed page (approx 48 lines or so) are inherently broken and must be re-written. Nevertheless, I find 8-space indentation too wasteful, 4-space indentation too cumbersome to type, and 1-space indentation unreadable. So I stick with 2. But I'm OK with 4 if it helps others read the code. On the evil side, I had seen people who insist on using 1 space per indentation level. [snip] Yes, that's Pure Evil(tm). Just one step away from the atrocious inconsistent indentation. (Believe me, I've seen *professional* programmers insert random amounts of space just so they satisfy the law of indentation, but it's completely inconsistent across blocks. Very annoying to read.) T -- I'm not childish; I'm just in touch with the child within!
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 05:53:54PM -0800, Steve Lamb wrote: Tom wrote: Significant whitespace? Shudder, that brings back crusty old memories of Fortran. I have great fondness for fortran because of the wonderful mathematical algorithms in LinPack, but I have no fondness for significant whitespace. And? Does Fortran's rules map to Pythons? I often find that people who grouse about the whitespace are people who have never touched Python. Myself included before I touched Python. I can say this. I spent more time grousing about it in a few months than it has ever impacted my coding style in the years since. Have you touched Python? No. I should have said that in my post. Do whitespace mistakes cause compile time errors? The frustrating thing about fortran was variable names that started with C could be interpreted as comments not indented correctly, which would just cause that line to be skipped. Integer literals not indented correctly could be interpreted as line numbers and would really cause havoc with computed gotos. I.e., they were as super-frustrating to debug as misspelled variable names in a declaration-less language, or the types of bizarre situtations you get into in C when you start overwriting memory. If whitespace mistakes are always caught at compile-time, then I probably wouldn't care about them either. So I'm not bashing python; having never used it: I'm bashing languages where syntatic mistakes are not caught at compile-time. I have no idea if Python is in that category or not.
Re: Tabs v.s. spaces
Tom == Tom [EMAIL PROTECTED] writes: Tom Do whitespace mistakes cause compile time errors? The frustrating Tom thing about fortran was variable names that started with C could be Tom interpreted as comments not indented correctly, which would just Tom cause that line to be skipped. Normally Python has no distinction between compile time and run time: it is interpreted (there is a project called Psyco to compile Python code, though). But yes, wrong whitespace stops you from running your code. Unlike Fortran, when this happen you happily accept that it is your error. E.g., you will not be able to run your code if you write def fibo(n): curr = 1 next = 1 # wrong indentation - can't run i = 0 while i n: curr, next = next, next+curr # no indent after while, fail i = i + 1 return curr instead of def fibo(n): curr = 1 next = 1 i = 0 while i n: curr, next = next, next+curr i = i + 1 return curr because the interpretor won't understand what you mean. I bet that if you try to write the first version you'll happily say okay, my fault. Tom Integer literals not indented correctly could be interpreted as Tom line numbers and would really cause havoc with computed gotos. That's fixed-width nonsense does not appear in Python at all. Tom I.e., they were as super-frustrating to debug as misspelled Tom variable names in a declaration-less language, or the types of Tom bizarre situtations you get into in C when you start overwriting Tom memory. Python is declaration-less, to let you down. But then, unit testing is easier in Python than in C. Tom If whitespace mistakes are always caught at compile-time, then I Tom probably wouldn't care about them either. So I'm not bashing Tom python; having never used it: I'm bashing languages where syntatic Tom mistakes are not caught at compile-time. I have no idea if Python Tom is in that category or not. There are whitespace errors that are not caught on compile time. In the code above, if you write def fibo(n): curr = 1 next = 1 i = 0 while i n: curr, next = next, next+curr i = i + 1 return curr Python will happily run i = i+1 outside the while loop. But then, that's the natural thing to expect when any sane person read the code. Regards, Isaac.
Re: Tabs v.s. spaces (was Re: Programming first steps.)
Tom wrote:
Do whitespace mistakes cause compile time errors? The frustrating thing
about fortran was variable names that started with C could be
interpreted as comments not indented correctly, which would just cause
that line to be skipped. Integer literals not indented correctly could
be interpreted as line numbers and would really cause havoc with
computed gotos. I.e., they were as super-frustrating to debug as
misspelled variable names in a declaration-less language, or the types
of bizarre situtations you get into in C when you start overwriting
memory.
Trust me, in Python were anything like that I would be right there with
ya. It isn't. Someone else address your specific questions so I won't here.
I just wanted to add that basically Python boils down to this:
It's the code you should write without the braces and semicolons.
Seriously. Take a piece of code from Perl or C or PHP or any other
language which has those constructs which is written properly (IE, human
readable) then just remove the braces and semicolons and you have the basic
equivolant of Python code. Granted the keywords and syntax are different but
the idea is the same. It's just properly indented code without braces and
semicolons. Here's an example that shows that nicely. Notice my argument
lists on both calls to self.FileList.AppendItem():
def Init_FileList(self):
'''Setup the initial tree for the FileList view'''
root_node = self.FileList.AddRoot('Mail dirs',-1,-1,NULL)
for dir in vars.maildirs:
dir_name = wxTreeItemData(dir)
dir_node = self.FileList.AppendItem(root_node, dir, -1, -1,
dir_name)
try:
for file in os.listdir(dir):
filepath = wxTreeItemData(dir + '/' + file)
if os.path.isfile(filepath.GetData()):
self.FileList.AppendItem(dir_node, file, -1, -1,
filepath)
except OSError:
self.err('Directory %s does not exist' % (dir))
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
---+-
pgpV5N4wk4aWt.pgp
Description: PGP signature
Re: Tabs v.s. spaces
On Mon, Nov 17, 2003 at 08:56:49PM -0500, H. S. Teoh wrote: | Nevertheless, I find 8-space indentation too wasteful, 4-space | indentation too cumbersome to type, and 1-space indentation | unreadable. Your editor should do that for you! :-) e.g. set softtabstop=4 in vim will allow you to have 4-character indentation by pressing the tab key and outdentation by pressing backspace, but the file will contain spaces instead of tabs. I would be surprised if other editors did not have a similar feature. Personally I prefer 8-space indentation, though. Cameron.
Re: Tabs v.s. spaces
On Mon, Nov 17, 2003 at 08:56:49PM -0500, H. S. Teoh wrote: Well, that's a whole 'nother can of worms. I firmly believe that all functions longer than one printed page (approx 48 lines or so) are inherently broken and must be re-written. Nevertheless, I find 8-space indentation too wasteful, 4-space indentation too cumbersome to type, and 1-space indentation unreadable. So I stick with 2. But I'm OK with 4 if it helps others read the code. Hear, hear. Yes, 8-space indentation is a matter of pressing the Tab key, but it's a bit too big.. I've always stuck with two spaces. Note that if you want to quickly format your code with tab-character indentation (== 8 spaces), I like astyle -t file. Works like a charm. I've only tried it with C/C++ code so I don't know whether it works for other kinds of files. -- Joshua Kwan pgp0Hf91rToA6.pgp Description: PGP signature
Re: Tabs v.s. spaces
On Mon, Nov 17, 2003 at 08:56:49PM -0500, H. S. Teoh wrote: Yes, that's Pure Evil(tm). Just one step away from the atrocious inconsistent indentation. (Believe me, I've seen *professional* programmers insert random amounts of space just so they satisfy the law of indentation, but it's completely inconsistent across blocks. Very annoying to read.) I suspect you meant to use quotes there, not asterisks. :) I wish throwing things through indent didn't ruin CVS logs ... -- Glenn Maynard
Re: Tabs v.s. spaces (was Re: Programming first steps.)
H. S. Teoh dijo [Mon, Nov 17, 2003 at 08:47:27PM -0500]: *chalks up one more reason to avoid Python like the plague...* Uh, care to rewrite that since Python is now on 2.3 and 1.5.2 is several years old? [snip] That doesn't negate the fact that I find significant whitespace rather atrocious. I really rather use a language where I'm free to format the code the way I want it, to maximally convey its meaning, rather than to be forced to write it a certain way because some genius decided that whitespace should be significant. I think you should really take a look at the Whitespace programming language [1], it will make you love Python. Greetings, [1] http://compsoc.dur.ac.uk/whitespace/ -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
