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

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

Re: PEP8 and 4 spaces

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: PEP8 and 4 spaces Paul Sokolovsky <pmiscml@gmail.com> - 2014-07-03 21:07 +0300
    Re: PEP8 and 4 spaces wxjmfauth@gmail.com - 2014-07-03 12:22 -0700
    Re: PEP8 and 4 spaces Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-04 01:21 +0000
      Re: PEP8 and 4 spaces Chris Angelico <rosuav@gmail.com> - 2014-07-04 11:30 +1000
        Re: PEP8 and 4 spaces Roy Smith <roy@panix.com> - 2014-07-03 21:37 -0400
      Re: PEP8 and 4 spaces Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-07-04 18:55 +1200
        Re: PEP8 and 4 spaces Lie Ryan <lie.1296@gmail.com> - 2014-07-04 19:29 +0100
          Re: PEP8 and 4 spaces Roy Smith <roy@panix.com> - 2014-07-04 15:04 -0400
            Re: PEP8 and 4 spaces Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-04 20:50 +0100
          Re: PEP8 and 4 spaces Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-07-05 11:17 +1200
            Re: PEP8 and 4 spaces Tim Chase <python.list@tim.thechases.com> - 2014-07-04 18:35 -0500
        Re: PEP8 and 4 spaces Travis Griggs <travisgriggs@gmail.com> - 2014-07-05 00:51 -0700

#73913 — Re: PEP8 and 4 spaces

Hello,

On Fri, 4 Jul 2014 03:38:27 +1000
Chris Angelico <rosuav@gmail.com> wrote:

> On Fri, Jul 4, 2014 at 3:31 AM, Tobiah <tshepard@rcsreg.com> wrote:
> > Coworker takes PEP8 as gospel and uses 4 spaces
> > to indent.  I prefer tabs.  Boss want's us to
> > unify.
> 
> 1) PEP 8 is meant to be guidelines, *not* a set of hard-and-fast
> rules. 
> 2) Tabs let different people display the indents at different
> widths. 

That's exactly the problem with tabs - whatever you think your code
looks like with tabs, other people will see quite different picture.

Also, most people are not interested in doing mumbo-jumbo with tabs
settings, and have them set to standard 8-char tabs. So, any python
code which uses only tabs for indentation automatically violates
4-space convention (and mixing tabs and spaces is nowadays prohibited
in Python).

Summing up: if you care about other human beings, use spaces. If you
don't care about other human beings, you may use tabs, but other human
beings surely will take how you treat them into account ;-).


-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

[toc] | [next] | [standalone]

#73916

Le jeudi 3 juillet 2014 20:07:28 UTC+2, Paul Sokolovsky a écrit :
> Hello,
> 
> 
> 
> On Fri, 4 Jul 2014 03:38:27 +1000
> 
> Chris Angelico <rosuav@gmail.com> wrote:
> 
> 
> 
> > On Fri, Jul 4, 2014 at 3:31 AM, Tobiah <tshepard@rcsreg.com> wrote:
> 
> > > Coworker takes PEP8 as gospel and uses 4 spaces
> 
> > > to indent.  I prefer tabs.  Boss want's us to
> 
> > > unify.
> 
> > 
> 
> > 1) PEP 8 is meant to be guidelines, *not* a set of hard-and-fast
> 
> > rules. 
> 
> > 2) Tabs let different people display the indents at different
> 
> > widths. 
> 
> 
> 
> That's exactly the problem with tabs - whatever you think your code
> 
> looks like with tabs, other people will see quite different picture.
> 
> 
> 
> Also, most people are not interested in doing mumbo-jumbo with tabs
> 
> settings, and have them set to standard 8-char tabs. So, any python
> 
> code which uses only tabs for indentation automatically violates
> 
> 4-space convention (and mixing tabs and spaces is nowadays prohibited
> 
> in Python).
> 
> 
> 
> Summing up: if you care about other human beings, use spaces. If you
> 
> don't care about other human beings, you may use tabs, but other human
> 
> beings surely will take how you treat them into account ;-).
> 
> 
> 
> 
> 
> -- 
> 
> Best regards,
> 
>  Paul                          mailto:pmiscml@gmail.com


"Tabulation", the key, the code point, the tab stop have been
created for humans beeings.

Today, at Unicode time, there are only naive ascii people,
who think a code point/space can be replaced by a set of
characters.

jmf

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

#73932

On Thu, 03 Jul 2014 21:07:28 +0300, Paul Sokolovsky wrote:

> Hello,
> 
> On Fri, 4 Jul 2014 03:38:27 +1000
> Chris Angelico <rosuav@gmail.com> wrote:
> 
>> On Fri, Jul 4, 2014 at 3:31 AM, Tobiah <tshepard@rcsreg.com> wrote:
>> > Coworker takes PEP8 as gospel and uses 4 spaces to indent.  I prefer
>> > tabs.  Boss want's us to unify.
>> 
>> 1) PEP 8 is meant to be guidelines, *not* a set of hard-and-fast rules.
>> 2) Tabs let different people display the indents at different widths.
> 
> That's exactly the problem with tabs - whatever you think your code
> looks like with tabs, other people will see quite different picture.

Why do you consider this a problem?

The only rational reason I can think of is that you are concerned about 
line widths. If I write code with tabs set to two spaces, indent five 
times, and then write 50 characters of code, I'll see a total line width 
of 60 columns. Somebody who views tabs as four spaces will see a width of 
70, and someone else who views them as eight spaces will see a width of 
90 columns. So I can see that's somewhat of a problem, but not a huge one.


> Also, most people are not interested in doing mumbo-jumbo with tabs
> settings, and have them set to standard 8-char tabs. So, any python code
> which uses only tabs for indentation automatically violates 4-space
> convention

"Mumbo-jumbo"? In any decent editor, it's a single setting. In kwrite I 
go Settings > Configure Editor, click the Editing icon, and there's a 
"Tab width" field right there. Hardly mumbo-jumbo.

In any case, the 4-space convention is just a convention. If you're 
willing to go against PEP 8 and use tabs, going against PEP 8 and using 8-
column tab settings shouldn't worry you.


> (and mixing tabs and spaces is nowadays prohibited in Python).

Yes, that's because the algorithm used by the parser to determine the 
indentation level may not give the same answer as a human reader, in the 
presence of mixed tabs and spaces. In any case, in the entire history of 
the space/tab argument, I'm not aware of a single person who recommended 
mixed space/tabs for indents. There are two standard solutions for the 
problem of indenting code, not three: use spaces, or use tabs, but not 
"arbitrarily pick one or the other each time you indent".


> Summing up: if you care about other human beings, use spaces. If you
> don't care about other human beings, you may use tabs, but other human
> beings surely will take how you treat them into account ;-).

Ha ha, that's funny, I would have said the opposite: if you care about 
keeping tools that expect spaces happy, use spaces, if you care about 
allowing people to configure the look of your code, or poor unfortunates 
who aren't using a programmer's editor, use tabs.


-- 
Steven

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

#73933

On Fri, Jul 4, 2014 at 11:21 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
>> Summing up: if you care about other human beings, use spaces. If you
>> don't care about other human beings, you may use tabs, but other human
>> beings surely will take how you treat them into account ;-).
>
> Ha ha, that's funny, I would have said the opposite: if you care about
> keeping tools that expect spaces happy, use spaces, if you care about
> allowing people to configure the look of your code, or poor unfortunates
> who aren't using a programmer's editor, use tabs.

Right. And hey. If you're a sufficiently competent programmer, you CAN
get away with not caring about other human beings: either because
you're so utterly valuable that people accept you despite your rough
edges... or because you just script away the differences :)

Now, if your *boss* doesn't understand about these things, it's
possible to lose your job over stupid stuff like style guides.
Although to be fair, I'd been planning to quit for a long time, and
the style guide was the last in a long line of problems, so when I
kicked back and said basically "No, your style guide is a bad idea",
it ended up with us parting ways. But that's a separate point.

ChrisA

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

#73934

In article <mailman.11478.1404437416.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Fri, Jul 4, 2014 at 11:21 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
> >> Summing up: if you care about other human beings, use spaces. If you
> >> don't care about other human beings, you may use tabs, but other human
> >> beings surely will take how you treat them into account ;-).
> >
> > Ha ha, that's funny, I would have said the opposite: if you care about
> > keeping tools that expect spaces happy, use spaces, if you care about
> > allowing people to configure the look of your code, or poor unfortunates
> > who aren't using a programmer's editor, use tabs.
> 
> Right. And hey. If you're a sufficiently competent programmer, you CAN
> get away with not caring about other human beings: either because
> you're so utterly valuable that people accept you despite your rough
> edges... or because you just script away the differences :)
> 
> Now, if your *boss* doesn't understand about these things, it's
> possible to lose your job over stupid stuff like style guides.
> Although to be fair, I'd been planning to quit for a long time, and
> the style guide was the last in a long line of problems, so when I
> kicked back and said basically "No, your style guide is a bad idea",
> it ended up with us parting ways. But that's a separate point.
> 
> ChrisA

The way I figure it, there are two things which have sucked up more 
time, effort, and productivity than anything else.  Buffer overrun bugs, 
and arguments about whitespace (and placement of braces in those sorts 
of languages).  I'm not sure which order they go in.

Solving buffer overruns is easy; you use bounds-checked containers, or 
languages which don't expose raw memory.  Killing whitespace arguments 
seems to be a far more intractable problem.

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

#73939

Steven D'Aprano wrote:

>>That's exactly the problem with tabs - whatever you think your code
>>looks like with tabs, other people will see quite different picture.
> 
> Why do you consider this a problem?

It's a problem if you try to use tabs for lining things
up in a tabular fashion in your source code.

The solution is not to use tabs for that -- only use
tabs for indentation, and use spaces for everything
else. Or, as PEP 8 suggests, don't try to line things
up in the first place.

I know it's ironic that tabs are no good for tabulation.
But it's unavoidable in a plain text format that doesn't
carry any metadata about how to interpret the tabs.

-- 
Greg

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

#73974

On 04/07/14 07:55, Gregory Ewing wrote:
> Steven D'Aprano wrote:
>
>>> That's exactly the problem with tabs - whatever you think your code
>>> looks like with tabs, other people will see quite different picture.
>>
>> Why do you consider this a problem?
>
> It's a problem if you try to use tabs for lining things
> up in a tabular fashion in your source code.
>
> The solution is not to use tabs for that -- only use
> tabs for indentation, and use spaces for everything
> else. Or, as PEP 8 suggests, don't try to line things
> up in the first place.

PEP8 suggests using this style of method invocation:

     obj.method(foo,
                bar,
                baz)

which is an effect impossible to do correctly with tabs alone. If you 
want to follow this style strictly, you end up having to either mix tabs 
and spaces, or just use spaces, or as I prefer it, avoid the issue 
altogether:

     obj.method(
         foo,
         bar,
         baz,
     )

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

#73976

In article <mailman.11507.1404498596.18130.python-list@python.org>,
 Lie Ryan <lie.1296@gmail.com> wrote:

> PEP8 suggests using this style of method invocation:
> 
>      obj.method(foo,
>                 bar,
>                 baz)
> 
> which is an effect impossible to do correctly with tabs alone.

If course you can do it with tabs. Just make sure all your method names 
are 7 letters long :-)

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

#73977

On 04/07/2014 20:04, Roy Smith wrote:
> In article <mailman.11507.1404498596.18130.python-list@python.org>,
>   Lie Ryan <lie.1296@gmail.com> wrote:
>
>> PEP8 suggests using this style of method invocation:
>>
>>       obj.method(foo,
>>                  bar,
>>                  baz)
>>
>> which is an effect impossible to do correctly with tabs alone.
>
> If course you can do it with tabs. Just make sure all your method names
> are 7 letters long :-)
>

When the homework gets handed in I guess the lecturer will know who's 
read this thread :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

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

#73981

Lie Ryan wrote:
> PEP8 suggests using this style of method invocation:
> 
>     obj.method(foo,
>                bar,
>                baz)
> 
> which is an effect impossible to do correctly with tabs alone.

Yes, PEP 8 is self-contradictory in that regard.
I also happen to think that recommendation is insane
for other reasons as well, and cheerfully ignore it.

-- 
Greg

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

#73982

On 2014-07-05 11:17, Gregory Ewing wrote:
> > PEP8 suggests using this style of method invocation:
> > 
> >     obj.method(foo,
> >                bar,
> >                baz)
> > 
> > which is an effect impossible to do correctly with tabs alone.  
> 
> Yes, PEP 8 is self-contradictory in that regard.
> I also happen to think that recommendation is insane
> for other reasons as well, and cheerfully ignore it.

To be fair, in the same section[1] that example is given, it also
suggests

# More indentation included to distinguish this from the rest.
def long_function_name(
        var_one, var_two, var_three,
        var_four):
    print(var_one)

# Hanging indents should add a level.
foo = long_function_name(
    var_one, var_two,
    var_three, var_four)

both of which can be done with arbitrary indentation without the need
to mix tabs+spaces or use a non-integer multiple of
indentation-spaces.  I just use these two in all instances and (as
you, Greg, advise), "cheerfully ignore [the first form]"


The only time I intentionally violate the "don't do these" section

"""
# Arguments on first line forbidden when not using vertical alignment.
foo = long_function_name(var_one, var_two,
    var_three, var_four)
"""

is when defining options in optparse:

  parser.add_option("-v", "--verbose",
    help="be prolix",
    action="store_true",
    dest="verbose",
    default=False,
    )

as I find that a little easier to read when I'm scanning large blocks
of parser.add_option(...) calls, having the option stick out to the
right.

-tkc

[1] http://legacy.python.org/dev/peps/pep-0008/#indentation

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

#73989

> On Jul 4, 2014, at 11:29, Lie Ryan <lie.1296@gmail.com> wrote:
> 
>> On 04/07/14 07:55, Gregory Ewing wrote:
>> Steven D'Aprano wrote:
>> 
>>>> That's exactly the problem with tabs - whatever you think your code
>>>> looks like with tabs, other people will see quite different picture.
>>> 
>>> Why do you consider this a problem?
>> 
>> It's a problem if you try to use tabs for lining things
>> up in a tabular fashion in your source code.
>> 
>> The solution is not to use tabs for that -- only use
>> tabs for indentation, and use spaces for everything
>> else. Or, as PEP 8 suggests, don't try to line things
>> up in the first place.
> 
> PEP8 suggests using this style of method invocation:
> 
>    obj.method(foo,
>               bar,
>               baz)
> 
> which is an effect impossible to do correctly with tabs alone. If you want to follow this style strictly, you end up having to either mix tabs and spaces, or just use spaces, or as I prefer it, avoid the issue altogether:
> 
>    obj.method(
>        foo,
>        bar,
>        baz,
>    )

Ok, here's irony. I'm looking at that thinking "what the heck is he talking about?!?". And then my brain catches up. My mail reader is of course "modern" and does not use a mono space font. So the value of the along ed indent is lost anyway. But wasn't that what spaces were supposed to give us over tabs, some separation from the trading betwixt different editors? Chuckle.

Travis Griggs

[toc] | [prev] | [standalone]

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

csiph-web