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 (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 (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 (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 (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 (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: */
Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 11:13:59PM +0800, Cameron Patrick wrote: I believe that tabs aren't a problem with Python so long as they really do indent to a multiple of 8 spaces. Editors which interpret tabs differently are broken^W^W can cause problems when editing Python code with tabs and spaces mixed though. This seems to be Python's greatest Achille's Heel as well as one of its greatest assets. Working code in Python has a consistent look and feel. Improper indenting will give a descriptive error that is easy to track down. New programmers feel right at home with it, because it isn't all that significant of a change from psuedo-code outlines. 1. step 1 1.1 substep 1 1.2 substep 2... In addition, you're not forced to use a program like indent(1) or astyle(1) to enforce coding style; it's built into the Python interpretor. I have a love-hate relationship with the significant whitespace. 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 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]. Another problem. Try cut-n-paste in X between code that uses tabs[2]. Sometimes the tabs are not preserved. Very odd and annoying. In any case, the documentation about how tabs and spaces are interpreted in Python are in the Language Reference[3]. Here's the relavent passage: First, tabs are replaced (from left to right) by one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight (this is intended to be the same rule as used by Unix). The total number of spaces preceding the first non-blank character then determines the line's indentation. If you continue reading this passage, you will understand why the authors of Python (namely GvR) choose this. It's simple to implement scope via significant whitespace. 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 REFERENCES 1. http://www.linuxjournal.com/article.php?sid=5780 2. http://mail.python.org/pipermail/python-list/2001-December/075764.html 3. http://www.python.org/doc/current/ref/indentation.html -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpAJEKWCjID3.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 (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.
---+-
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 (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 (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 (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
