Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #10052 > unrolled thread

Re: PEP 8 and extraneous whitespace

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: PEP 8 and extraneous whitespace Terry Reedy <tjreedy@udel.edu> - 2011-07-21 18:45 -0400
    Re: PEP 8 and extraneous whitespace Roy Smith <roy@panix.com> - 2011-07-21 21:12 -0400
      Re: PEP 8 and extraneous whitespace Ed Leafe <ed@leafe.com> - 2011-07-21 22:11 -0500
      Re: PEP 8 and extraneous whitespace Ethan Furman <ethan@stoneleaf.us> - 2011-07-25 15:05 -0700
      Re: PEP 8 and extraneous whitespace Thomas Jollans <t@jollybox.de> - 2011-07-26 01:26 +0200
        Re: PEP 8 and extraneous whitespace AlienBaby <matt.j.warren@gmail.com> - 2011-07-26 05:46 -0700
          Re: PEP 8 and extraneous whitespace Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-27 10:49 +1000
    Re: PEP 8 and extraneous whitespace Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-07-22 10:11 +0200
      Re: PEP 8 and extraneous whitespace Thomas Jollans <t@jollybox.de> - 2011-07-22 12:23 +0200
      Re: PEP 8 and extraneous whitespace Neil Cerutti <neilc@norwich.edu> - 2011-07-22 12:59 +0000
        Re: PEP 8 and extraneous whitespace Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-22 12:13 -0600
          Re: PEP 8 and extraneous whitespace Neil Cerutti <neilc@norwich.edu> - 2011-07-22 19:05 +0000
            Re: PEP 8 and extraneous whitespace John Gordon <gordon@panix.com> - 2011-07-22 19:13 +0000
              Re: PEP 8 and extraneous whitespace Neil Cerutti <neilc@norwich.edu> - 2011-07-22 19:15 +0000
              Re: PEP 8 and extraneous whitespace Brandon Harris <brandon.harris@reelfx.com> - 2011-07-22 14:53 -0500
              Re: PEP 8 and extraneous whitespace Chris Rebert <clp2@rebertia.com> - 2011-07-22 13:56 -0700
                Re: PEP 8 and extraneous whitespace Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-28 01:24 +0200
                  Re: PEP 8 and extraneous whitespace "OKB (not okblacke)" <brenNOSPAMbarn@NObrenSPAMbarn.net> - 2011-07-28 06:18 +0000
                    Re: PEP 8 and extraneous whitespace Chris Angelico <rosuav@gmail.com> - 2011-07-29 20:25 +1000
                      Re: PEP 8 and extraneous whitespace "OKB (not okblacke)" <brenNOSPAMbarn@NObrenSPAMbarn.net> - 2011-07-29 18:45 +0000
                        Re: PEP 8 and extraneous whitespace Chris Angelico <rosuav@gmail.com> - 2011-07-30 07:18 +1000
                          Re: PEP 8 and extraneous whitespace "OKB (not okblacke)" <brenNOSPAMbarn@NObrenSPAMbarn.net> - 2011-07-31 01:23 +0000
                            Re: PEP 8 and extraneous whitespace Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-31 18:10 +1200
                            Re: PEP 8 and extraneous whitespace Ben Finney <ben+python@benfinney.id.au> - 2011-07-31 17:56 +1000
                    Re: PEP 8 and extraneous whitespace Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-08-01 17:16 +0200
              Re: PEP 8 and extraneous whitespace Corey Richardson <kb1pkl@aim.com> - 2011-07-22 17:17 -0400
              Re: PEP 8 and extraneous whitespace Michael Brown <Michael@invalid.invalid> - 2011-07-24 13:07 +0000
                Re: PEP 8 and extraneous whitespace Zero Piraeus <schesis@gmail.com> - 2011-07-24 11:08 -0400
                  Re: PEP 8 and extraneous whitespace Ben Finney <ben+python@benfinney.id.au> - 2011-07-25 07:37 +1000
                    Re: PEP 8 and extraneous whitespace Neil Cerutti <neilc@norwich.edu> - 2011-07-25 11:37 +0000
      Re: PEP 8 and extraneous whitespace Michiel Overtoom <motoom@xs4all.nl> - 2011-07-22 19:05 +0200
        Re: PEP 8 and extraneous whitespace rusi <rustompmody@gmail.com> - 2011-07-22 10:43 -0700
          Re: PEP 8 and extraneous whitespace Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-22 12:14 -0600
      Re: PEP 8 and extraneous whitespace Chris Angelico <rosuav@gmail.com> - 2011-07-23 03:27 +1000

Page 1 of 2  [1] 2  Next page →

#10052 — Re: PEP 8 and extraneous whitespace

On 7/21/2011 2:46 PM, Andrew Berg wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> On 2011.07.21 01:32 PM, Thomas Jollans wrote:
>> So, the PEP says: do not align operators. End of story.
> I'm pretty sure that colons, commas and equals signs are not operators.

Whether or not they are intended, the rationale is that lining up does 
not work with proportional fonts. However, I have IDLE using fixed-space 
font and I line things up how I want. PEP 8 only applies to new stdlib 
code. For anything else, it is advisory on a point by point basis.

-- 
Terry Jan Reedy

[toc] | [next] | [standalone]

#10056

In article <mailman.1336.1311288320.1164.python-list@python.org>,
 Terry Reedy <tjreedy@udel.edu> wrote:

> Whether or not they are intended, the rationale is that lining up does 
> not work with proportional fonts.

There are very few things I am absolutely religious about, but 
programming in a fixed width font is one of them.

[toc] | [prev] | [next] | [standalone]

#10063

Religious fervor is one thing; freedom of religion is another!  ;-)

We strive for readability in our code, yet every printed material designed to be read, such as books, newspapers, etc., uses a proportional font. I switched to proportional fonts years ago, and am only reluctantly using fixed width because of vim. It doesn't take as long to get used to as you might think. 

-- Ed

Sent from my iPhone, so please excuse any top-posting.

On Jul 21, 2011, at 8:12 PM, Roy Smith <roy@panix.com> wrote:

> There are very few things I am absolutely religious about, but 
> programming in a fixed width font is one of them.

[toc] | [prev] | [next] | [standalone]

#10313

Ed Leafe wrote:
> Religious fervor is one thing; freedom of religion is another!  ;-)
> 
> We strive for readability in our code, yet every printed material
 > designed to be read, such as books, newspapers, etc., uses a
 > proportional font.

The books I purchase use monospaced fonts for code examples.  Yours don't?

~Ethan~

[toc] | [prev] | [next] | [standalone]

#10316

On 26/07/11 00:05, Ethan Furman wrote:
> Ed Leafe wrote:
>> Religious fervor is one thing; freedom of religion is another!  ;-)
>>
>> We strive for readability in our code, yet every printed material
>> designed to be read, such as books, newspapers, etc., uses a
>> proportional font.
> 
> The books I purchase use monospaced fonts for code examples.  Yours don't?

Strange that. Most do, but that's really just tradition.

I have Bjarne Stroustrup's "The C++ Programming Language" on my shelf,
and that prints code in a proportional font.

There are two possible reasons to prefer a monospaced font for code:

 1. You're used to it: tradition. This is a legacy of the era when
    computers simply didn't display proportional fonts.

 2. Your editor (my usual preference, Vim, is an example) doesn't
    support proportional fonts. This is a legacy of the era when
    computers simply didn't display proportional fonts.

Code is different from prose. We parse it so differently that printing
it in a monospaced font doesn't significantly hurt readability - but it
doesn't make it more readable either.

In the end, it really doesn't matter. This is probably why I enjoyed
writing this message so much.

Thomas

[toc] | [prev] | [next] | [standalone]

#10331

> (on limiting line lengths)..

I didn't see this mentioned;

I have a hard time keeping python code limited to 80 char line lengths
_because_ indentation is significant, and can end up consuming quite a
lot of linespace itself.  Couple that with a liking for
long_memorable_explanatory_names, and an 80 char limit causes (me)
problems.

So I tend to use the print margin just as a guide. If I am over it,
then don't panic! just don't put any new elements onto the line, and
maybe step back and think about what your doing just in case theres
another clear way that avoids the issue.

[toc] | [prev] | [next] | [standalone]

#10359

AlienBaby wrote:

>> (on limiting line lengths)..
> 
> I didn't see this mentioned;
> 
> I have a hard time keeping python code limited to 80 char line lengths
> _because_ indentation is significant, 

Are you suggesting that if indentation was not significant, you wouldn't
write such long lines? *wink*

Whether significant or not, the fact that it is there at all is what
matters.

> and can end up consuming quite a lot of linespace itself.

If you are using 8 space indents, do yourself, and your readers, a favour
and change to 4 spaces.

If you regularly have more than four or five nested indents, I would
seriously advise you to refactor your code into a flatter structure. I've
done a quick (and unscientific) survey of my code, and roughly 80% of it is
between 1 and 3 indents (inclusive). Only a tiny portion reaches 6 indents.
If I've ever gone to 7, and I can't find it with a quick random survey.


> Couple that with a liking for 
> long_memorable_explanatory_names, and an 80 char limit causes (me)
> problems.

Names can be too long as well as too short. If you are a carpenter, you
surely wouldn't bang nails with a
metal_manually_operated_hammering_device_with_nail_removing_attachment, you
would use a hammer.

But even with long names, if you are *regularly* going over 80 characters,
you may be doing something wrong. 80 characters is a lot -- most of my
lines of code are under 50, including indentation. I haven't seen your
code, so I could be way off base here, but I expect you're using deeply
hierarchical data structures, and violating the Law of Demeter:

paper = paper_boy.give_newspaper()
# Pay the paper boy.
paper_boy.collect_payment(customer.backpocket.wallet(2.0, tip=300.00))

Don't let the paper boy reach into your wallet and pay himself!



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#10084

Am 22.07.2011 00:45 schrieb Terry Reedy:

> Whether or not they are intended, the rationale is that lining up does
> not work with proportional fonts.

Who on earth would use proportional fonts in programming?!

[toc] | [prev] | [next] | [standalone]

#10090

On 22/07/11 10:11, Thomas Rachel wrote:
> Am 22.07.2011 00:45 schrieb Terry Reedy:
> 
>> Whether or not they are intended, the rationale is that lining up does
>> not work with proportional fonts.
> 
> Who on earth would use proportional fonts in programming?!

Why not? I don't (it doesn't work with vim), but it happens to be the
default of the excellent programmer's editor SciTE.

[toc] | [prev] | [next] | [standalone]

#10105

On 2011-07-22, Thomas Rachel
<nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de>
wrote:
> Am 22.07.2011 00:45 schrieb Terry Reedy:
>> Whether or not they are intended, the rationale is that lining
>> up does not work with proportional fonts.
>
> Who on earth would use proportional fonts in programming?!

Under the assumption that leading white space is important for
code formatting, but that all alignment after that is
unimportant. Peek at Stroustrup's writing for examples. It really
doesn't take much time at all to get used to it.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#10129

On Fri, Jul 22, 2011 at 6:59 AM, Neil Cerutti <neilc@norwich.edu> wrote:
> Under the assumption that leading white space is important for
> code formatting, but that all alignment after that is
> unimportant.

...unless you're trying to adhere to a line length limit.  "80
characters" is a lot easier to do in a fixed-width font, and "10
inches" or "400 pixels" or however you want to do it in a proportional
font effectively limits you to using that specific font, at that
specific size.

[toc] | [prev] | [next] | [standalone]

#10136

On 2011-07-22, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Fri, Jul 22, 2011 at 6:59 AM, Neil Cerutti <neilc@norwich.edu> wrote:
>> Under the assumption that leading white space is important for
>> code formatting, but that all alignment after that is
>> unimportant.
>
> ...unless you're trying to adhere to a line length limit.  "80
> characters" is a lot easier to do in a fixed-width font, and
> "10 inches" or "400 pixels" or however you want to do it in a
> proportional font effectively limits you to using that specific
> font, at that specific size.

You can fit much more code per unit of horizontal space with a
proportionally spaced font. As a result, that issue, while valid,
is significantly reduced.

Of some concern are consecutive underscores. Unless your font is
designed specifically for programming, it can be hard to
distinguish from a single underscore. You generally need to use a
programming-specialized font even when using fixed width, though,
so I'm not sure this issue is unique.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#10138

In <98u00kFnfiU1@mid.individual.net> Neil Cerutti <neilc@norwich.edu> writes:

> You can fit much more code per unit of horizontal space with a
> proportionally spaced font. As a result, that issue, while valid,
> is significantly reduced.

Is it?  I assume one major reason for the 80-character limit is to help
the poor sod who will eventually get stuck working with your code on an
80-column fixed width terminal window.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#10139

On 2011-07-22, John Gordon <gordon@panix.com> wrote:
> In <98u00kFnfiU1@mid.individual.net> Neil Cerutti <neilc@norwich.edu> writes:
>> You can fit much more code per unit of horizontal space with a
>> proportionally spaced font. As a result, that issue, while
>> valid, is significantly reduced.
>
> Is it?  I assume one major reason for the 80-character limit is
> to help the poor sod who will eventually get stuck working with
> your code on an 80-column fixed width terminal window.

It's probably much better for making hard-copies of code than for
sharing directly, that is true. Your recipient would be forced to
us a similar font.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#10146

Poor sod? Makes it sound bad when you say it like that. I am not forced 
to work at that fixed width, but when I work with code, I often have my 
vim session split vertically and it's super important to keep things at 
80 character to quickly read/edit code.

Brandon L. Harris

On 07/22/2011 02:13 PM, John Gordon wrote:
> In<98u00kFnfiU1@mid.individual.net>  Neil Cerutti<neilc@norwich.edu>  writes:
>
>> You can fit much more code per unit of horizontal space with a
>> proportionally spaced font. As a result, that issue, while valid,
>> is significantly reduced.
> Is it?  I assume one major reason for the 80-character limit is to help
> the poor sod who will eventually get stuck working with your code on an
> 80-column fixed width terminal window.
>

[toc] | [prev] | [next] | [standalone]

#10153

On Fri, Jul 22, 2011 at 12:13 PM, John Gordon <gordon@panix.com> wrote:
> In <98u00kFnfiU1@mid.individual.net> Neil Cerutti <neilc@norwich.edu> writes:
>
>> You can fit much more code per unit of horizontal space with a
>> proportionally spaced font. As a result, that issue, while valid,
>> is significantly reduced.
>
> Is it?  I assume one major reason for the 80-character limit is to help
> the poor sod who will eventually get stuck working with your code on an
> 80-column fixed width terminal window.

What environments with that limitation are still in common use?
It's not the '70s anymore; I think we can safely increase the max
column width a bit.

Cheers,
Chris
--
http://rebertia.com

[toc] | [prev] | [next] | [standalone]

#10410

Chris Rebert wrote:

> John Gordon wrote:
>> Neil Cerutti writes:
>>> You can fit much more code per unit of horizontal space with a
>>> proportionally spaced font. As a result, that issue, while valid,
>>> is significantly reduced.
>>
>> Is it?  I assume one major reason for the 80-character limit is to help
>> the poor sod who will eventually get stuck working with your code on an
>> 80-column fixed width terminal window.
> 
> What environments with that limitation are still in common use?

TTYs are present on Unices and compatible OSes everywhere today (even more 
so as Python is evolving into a more powerful replacement for Bourne-shell 
based shell command languages), and there are sophisticated graphic-mode 
IDEs (not IDLE) where you want to have more than the source code column 
visible at the same time.

Having too long code lines is detrimental to readability there, because even 
though you can scroll, horizontal scrolling is a PITA.  Automatic word-wrap, 
where available, really is not a solution; it is a bad workaround to a 
problem caused by the original author of the source code that can be easily 
avoided by them taking more care while coding.

> It's not the '70s anymore; I think we can safely increase the max
> column width a bit.

You're wrong.  It is not only an issue of output device/window, but also 
simply of readability.  In particular, humans have difficulties reading text 
that is larger than about 60 characters, both due to constrainted view angle 
and increased eye movement from the end of one line to the beginning of the 
next one (the greater that distance, the harder to keep track of the text).  
One can learn from the newspaper and pocketbook publishers how easily 
readable text should be formatted (but one must not overdo as some of them 
do).
 
-- 
PointedEars

Bitte keine Kopien per E-Mail. / Please do not Cc: me.

[toc] | [prev] | [next] | [standalone]

#10432

Thomas 'PointedEars' Lahn wrote:
>  Automatic word-wrap, where available, really is not a solution; it
> is a bad workaround to a problem caused by the original author of
> the source code that can be easily avoided by them taking more care
> while coding. 

    	I think exactly the opposite.  The source file should reflect the 
semantic organization of the code, without extraneous concessions to 
visual display (like "lining things up" with spaces or splitting long 
lines with hard newlines).  The editor should present the code nicely.  
People already argue for this general mindset when they say that "any 
good edit will let you set the tab width", etc.

-- 
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is
no path, and leave a trail."
	--author unknown

[toc] | [prev] | [next] | [standalone]

#10509

On Thu, Jul 28, 2011 at 4:18 PM, OKB (not okblacke)
<brenNOSPAMbarn@nobrenspambarn.net> wrote:
> Thomas 'PointedEars' Lahn wrote:
>>  Automatic word-wrap, where available, really is not a solution; it
>> is a bad workaround to a problem caused by the original author of
>> the source code that can be easily avoided by them taking more care
>> while coding.
>
>        I think exactly the opposite.  The source file should reflect the
> semantic organization of the code, without extraneous concessions to
> visual display (like "lining things up" with spaces or splitting long
> lines with hard newlines).  The editor should present the code nicely.
> People already argue for this general mindset when they say that "any
> good edit will let you set the tab width", etc.

That mandates that formatting NOT be a part of the language. I could
take C code and reformat it in various ways with a script, and easily
guarantee that the script won't affect the code by simply having it
only ever adjust whitespace. This concept simply won't work in Python.

Personally, I like to be able to format things according to where they
came from, or other criteria. Take a look at this code, for instance;
the post has highlighted the difference between 1 and 0, but otherwise
hasn't changed it:

http://thedailywtf.com/Articles/The-Shapes.aspx

Note how the formatting is beautifully consistent. Each line is
wrapped to a tidy 70 characters, or whatever it is (I haven't
counted). Each data row, therefore, has the same number of characters
in it. But is that useful? Would it not be far more useful to wrap
them each at their image widths? Yes, it might take a bit more
vertical space, but the source code would *look like the image* and
that massively helps readability. This is why a source code tidying
script can't fully grok readability; if a program looks at a sequence
of strings, how can it know where to break them? All of these
(hypothetical) examples are single string literals, broken across
lines:

-----
"This is string 1.\0"
"This is string 2, and it is longer.\0"
"String 3.\0"
-----
"This is a long paragraph of"
"text, which I have wrapped somewhat messily, and"
"which a good text"
"tidying program should be able to clean up"
"for me."
-----
"Usage: programname [options] [argument]\n"
"-f\tFooify\n"
"-b\tBarify\n"
"\n"
"argument should be either '5-minute' or 'course'\n"
-----

Can you write a script that perfectly handles these sorts of literals?
Considering that the divider in the first one might not be \0, but
might be any character or even string of characters, it's not really
possible for an editor to know where to wrap something; which means
that it's up to the programmer to make things readable. And that
demands that the programmer know what he's doing, and that the
programmer have the power to express what he's doing how he chooses.
Overly-strict formatting rules/guides remove that power.

ChrisA

[toc] | [prev] | [next] | [standalone]

#10532

Chris Angelico wrote:

> On Thu, Jul 28, 2011 at 4:18 PM, OKB (not okblacke)
>>        I think exactly the opposite.  The source file should re flect
>> the semantic organization of the code, without extraneous concessions
>> to visual display (like "lining things up" with spaces or splitting
>> long lines with hard newlines).  The editor should present the code
>> nicely. People already argue for this general mindset when they say
>> that "any good edit will let you set the tab width", etc. 
> 
> That mandates that formatting NOT be a part of the language. I could
> take C code and reformat it in various ways with a script, and easily
> guarantee that the script won't affect the code by simply having it
> only ever adjust whitespace. This concept simply won't work in Python.

    	"Formatting" is too general a term.  Obviously "formatting" in 
the lay sense is part of any language, since things like commas and 
parentheses matter.  What Python does that's unusual is pay attention to 
INDENTATION, which is a very specific part of formatting involving 
whitespace at the beginning of a line.  This isn't incompatible with 
what I outlined above.
 
> Personally, I like to be able to format things according to where they
> came from, or other criteria. Take a look at this code, for instance;
> the post has highlighted the difference between 1 and 0, but otherwise
> hasn't changed it:
> 
> http://thedailywtf.com/Articles/The-Shapes.aspx
> 
> Note how the formatting is beautifully consistent. Each line is
> wrapped to a tidy 70 characters, or whatever it is (I haven't
> counted). Each data row, therefore, has the same number of characters
> in it. But is that useful? Would it not be far more useful to wrap
> them each at their image widths? Yes, it might take a bit more
> vertical space, but the source code would *look like the image* and
> that massively helps readability. This is why a source code tidying
> script can't fully grok readability; if a program looks at a sequence
> of strings, how can it know where to break them? All of these
> (hypothetical) examples are single string literals, broken across
> lines:
> 
> -----
> "This is string 1.\0"
> "This is string 2, and it is longer.\0"
> "String 3.\0"
> -----
> "This is a long paragraph of"
> "text, which I have wrapped somewhat messily, and"
> "which a good text"
> "tidying program should be able to clean up"
> "for me."
> -----
> "Usage: programname [options] [argument]\n"
> "-f\tFooify\n"
> "-b\tBarify\n"
> "\n"
> "argument should be either '5-minute' or 'course'\n"
> -----
> 
> Can you write a script that perfectly handles these sorts of literals?
> Considering that the divider in the first one might not be \0, but
> might be any character or even string of characters, it's not really
> possible for an editor to know where to wrap something; which means
> that it's up to the programmer to make things readable. And that
> demands that the programmer know what he's doing, and that the
> programmer have the power to express what he's doing how he chooses.
> Overly-strict formatting rules/guides remove that power.

    	I don't think I understand what you're getting at there.  What 
would you mean "handling" those string literals?  I'm just talking about 
an editor that displays things in a way that respects semantic 
indentation that you put in.  I'm not talking about some sort of 
"script" that would take your second two examples and make them look 
nice.  The editor would need to know Python's string literal syntax to 
do that.  If you want to write things in those ways, okay, but my 
preference would be to always write them as one big string literal 
(e.g., triple-quoted), and then have the editor strip away shared 
indentation.

    	So I guess I was a bit unclear when I said "the editor should 
present the code nicely".  I just mean that the editor should present 
the code in a way that reflects the semantic indentation present, thus 
relieving users of the need to insert redundant linebreaks and 
whitespace to make things "line up".  I don't mean that it should try to 
"prettify" things in the way you seem to be suggesting.

    	As an aside, I don't think string literals are a great example case 
for these issues.  ALL whitespace (not just indentation), and all 
of everything else, always matters in string literals, so you do indeed 
have to put in explicit whitespace if you want explicit whitespace in 
the string.  In code, though, explicit whitespace is only needed to 
indicate semantically meaningful stuff, so you should only use it for 
that, and the editor should insert "visual space" (without actual 
whitespace characters in the file) to make things like up at the 
semantic indentation levels.

-- 
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is
no path, and leave a trail."
	--author unknown

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web