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

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

Continuing indentation

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

Contents

  Continuing indentation Skip Montanaro <skip.montanaro@gmail.com> - 2016-03-02 14:43 -0600
    Re: Continuing indentation Marko Rauhamaa <marko@pacujo.net> - 2016-03-02 22:50 +0200
      Re: Continuing indentation Ethan Furman <ethan@stoneleaf.us> - 2016-03-02 14:01 -0800
        Re: Continuing indentation Marko Rauhamaa <marko@pacujo.net> - 2016-03-03 00:10 +0200
          Re: Continuing indentation Skip Montanaro <skip.montanaro@gmail.com> - 2016-03-02 16:44 -0600
          Re: Continuing indentation Ethan Furman <ethan@stoneleaf.us> - 2016-03-02 14:51 -0800
          Re: Continuing indentation Ethan Furman <ethan@stoneleaf.us> - 2016-03-02 14:56 -0800
          Re: Continuing indentation Chris Angelico <rosuav@gmail.com> - 2016-03-03 10:46 +1100
          Re: Continuing indentation Steven D'Aprano <steve@pearwood.info> - 2016-03-03 13:15 +1100
          Re: Continuing indentation John Gordon <gordon@panix.com> - 2016-03-03 16:16 +0000
            Re: Continuing indentation Marko Rauhamaa <marko@pacujo.net> - 2016-03-03 18:47 +0200
              Re: Continuing indentation Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-03-03 18:06 +0000
                Re: Continuing indentation Marko Rauhamaa <marko@pacujo.net> - 2016-03-03 21:36 +0200
              Re: Continuing indentation Steven D'Aprano <steve@pearwood.info> - 2016-03-04 11:13 +1100
                Re: Continuing indentation INADA Naoki <songofacandy@gmail.com> - 2016-03-04 09:45 +0900
                Re: Continuing indentation Erik <python@lucidity.plus.com> - 2016-03-04 01:06 +0000
                Re: Continuing indentation INADA Naoki <songofacandy@gmail.com> - 2016-03-04 10:23 +0900
                  Re: Continuing indentation Steven D'Aprano <steve@pearwood.info> - 2016-03-04 14:48 +1100
                    Re: Continuing indentation cl@isbd.net - 2016-03-04 10:12 +0000
                      Re: Continuing indentation alister <alister.ware@ntlworld.com> - 2016-03-04 14:03 +0000
                        Re: Continuing indentation Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-04 08:25 -0700
                        Re: Continuing indentation Ethan Furman <ethan@stoneleaf.us> - 2016-03-04 09:36 -0800
                        Re: Continuing indentation sohcahtoa82@gmail.com - 2016-03-04 13:14 -0800
                          Re: Continuing indentation Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-04 21:20 +0000
                          Re: Continuing indentation Erik <python@lucidity.plus.com> - 2016-03-04 23:31 +0000
                          Re: Continuing indentation Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-04 23:45 +0000
                          Re: Continuing indentation Ethan Furman <ethan@stoneleaf.us> - 2016-03-04 15:53 -0800
                          Re: Continuing indentation Simon Ward <simon+python@bleah.co.uk> - 2016-03-05 00:23 +0000
                            Re: Continuing indentation sohcahtoa82@gmail.com - 2016-03-04 17:17 -0800
                              Re: Continuing indentation Ethan Furman <ethan@stoneleaf.us> - 2016-03-04 18:14 -0800
                              Re: Continuing indentation Ben Finney <ben+python@benfinney.id.au> - 2016-03-05 13:22 +1100
                              Re: Continuing indentation Tim Chase <python.list@tim.thechases.com> - 2016-03-04 20:49 -0600
                              Re: Continuing indentation srinivas devaki <mr.eightnoteight@gmail.com> - 2016-03-05 10:25 +0530
                              Re: Continuing indentation Ben Finney <ben+python@benfinney.id.au> - 2016-03-05 16:10 +1100
                          Re: Continuing indentation Erik <python@lucidity.plus.com> - 2016-03-05 00:52 +0000
                          Re: Continuing indentation Ben Finney <ben+python@benfinney.id.au> - 2016-03-05 12:05 +1100
                          Re: Continuing indentation Erik <python@lucidity.plus.com> - 2016-03-05 01:45 +0000
                          Re: Continuing indentation Steven D'Aprano <steve@pearwood.info> - 2016-03-05 18:17 +1100
                  Re: Continuing indentation alister <alister.ware@ntlworld.com> - 2016-03-04 13:59 +0000
                    Re: Continuing indentation Ben Finney <ben+python@benfinney.id.au> - 2016-03-05 10:41 +1100
                      Re: Continuing indentation sohcahtoa82@gmail.com - 2016-03-04 16:06 -0800
                        Re: Continuing indentation Ben Finney <ben+python@benfinney.id.au> - 2016-03-05 11:30 +1100
                        Re: Continuing indentation Ethan Furman <ethan@stoneleaf.us> - 2016-03-04 17:01 -0800
                Re: Continuing indentation Erik <python@lucidity.plus.com> - 2016-03-04 02:24 +0000
                Re: Continuing indentation Marko Rauhamaa <marko@pacujo.net> - 2016-03-04 08:28 +0200
    Re: Continuing indentation codewizard@gmail.com - 2016-03-02 15:46 -0800
      Re: Continuing indentation Chris Angelico <rosuav@gmail.com> - 2016-03-03 10:54 +1100
        Re: Continuing indentation Pete Forman <petef4+usenet@gmail.com> - 2016-03-03 00:23 +0000
      Re: Continuing indentation Carl Meyer <carl@oddbird.net> - 2016-03-02 17:02 -0700
        Re: Continuing indentation Steven D'Aprano <steve@pearwood.info> - 2016-03-03 13:22 +1100
          Re: Continuing indentation Ben Finney <ben+python@benfinney.id.au> - 2016-03-03 13:30 +1100
          Re: Continuing indentation Chris Angelico <rosuav@gmail.com> - 2016-03-03 13:33 +1100
          Re: Continuing indentation Ethan Furman <ethan@stoneleaf.us> - 2016-03-02 18:57 -0800
      Re: Continuing indentation Ben Finney <ben+python@benfinney.id.au> - 2016-03-03 11:30 +1100
      Re: Continuing indentation cl@isbd.net - 2016-03-03 10:22 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#104041

On Fri, Mar 4, 2016 at 7:03 AM, alister <alister.ware@ntlworld.com> wrote:
> On Fri, 04 Mar 2016 10:12:58 +0000, cl wrote:
>
>> Steven D'Aprano <steve@pearwood.info> wrote:
>>> On Fri, 4 Mar 2016 12:23 pm, INADA Naoki wrote:
>>>
>>>
>>> >>
>>> >> Indeed. I don't understand why, when splitting a condition such as
>>> >> this,
>>> >> people tend to put the operator at the end of each line.
>>> >>
>>> >>
>>> > Because PEP8 says:
>>> >
>>> >> The preferred place to break around a binary operator is after the
>>> > operator, not before it. http://pep8.org/#maximum-line-length
>>>
>>> PEP 8 is wrong :-)
>>>
>> Yes, I agree.  In my mind the logic is:-
>>
>>     IF xxx
>>         AND yyy AND zzz OR aaa
>>     THEN do something
>>
>> The PEP8 correct(er):-
>>
>>     IF xxx AND
>>          yyy AND zzz OR aaa
>>     THEN do something
>>
>> ... just seems all wrong and difficult to understand.
>
> not at all
> the split after the operator shows that their is more to that line
> splitting before & the reader could believe that the condition ends there
>
> PEP 8 is mos definitely correct on this one

I disagree. When I'm skimming over code, I find it unlikely that I'll
read the last token of the line. That's where trivialities like
arguments to function calls are found. It's much more likely that I'll
read the first token of the next line.

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

#104045

On 03/04/2016 07:25 AM, Ian Kelly wrote:
> On Fri, Mar 4, 2016 at 7:03 AM, alister <alister.ware@ntlworld.com> wrote:
>> On Fri, 04 Mar 2016 10:12:58 +0000, cl wrote:
>>
>>> Steven D'Aprano <steve@pearwood.info> wrote:
>>>> On Fri, 4 Mar 2016 12:23 pm, INADA Naoki wrote:
>>>>
>>>>
>>>>>>
>>>>>> Indeed. I don't understand why, when splitting a condition such as
>>>>>> this,
>>>>>> people tend to put the operator at the end of each line.
>>>>>>
>>>>>>
>>>>> Because PEP8 says:
>>>>>
>>>>>> The preferred place to break around a binary operator is after the
>>>>> operator, not before it. http://pep8.org/#maximum-line-length
>>>>
>>>> PEP 8 is wrong :-)
>>>>
>>> Yes, I agree.  In my mind the logic is:-
>>>
>>>      IF xxx
>>>          AND yyy AND zzz OR aaa
>>>      THEN do something
>>>
>>> The PEP8 correct(er):-
>>>
>>>      IF xxx AND
>>>           yyy AND zzz OR aaa
>>>      THEN do something
>>>
>>> ... just seems all wrong and difficult to understand.
>>
>> not at all
>> the split after the operator shows that their is more to that line
>> splitting before & the reader could believe that the condition ends there
>>
>> PEP 8 is mos definitely correct on this one
>
> I disagree. When I'm skimming over code, I find it unlikely that I'll
> read the last token of the line. That's where trivialities like
> arguments to function calls are found. It's much more likely that I'll
> read the first token of the next line.

And, as any pythonista knows: The conditions aren't over until the 
indentation changes.  ;)

--
~Ethan~

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

#104053

On Friday, March 4, 2016 at 6:03:48 AM UTC-8, alister wrote:
> On Fri, 04 Mar 2016 10:12:58 +0000, cl wrote:
> 
> > Steven D'Aprano <steve@pearwood.info> wrote:
> >> On Fri, 4 Mar 2016 12:23 pm, INADA Naoki wrote:
> >> 
> >> 
> >> >>
> >> >> Indeed. I don't understand why, when splitting a condition such as
> >> >> this,
> >> >> people tend to put the operator at the end of each line.
> >> >>
> >> >>
> >> > Because PEP8 says:
> >> > 
> >> >> The preferred place to break around a binary operator is after the
> >> > operator, not before it. http://pep8.org/#maximum-line-length
> >> 
> >> PEP 8 is wrong :-)
> >> 
> > Yes, I agree.  In my mind the logic is:-
> > 
> >     IF xxx
> >         AND yyy AND zzz OR aaa
> >     THEN do something
> > 
> > The PEP8 correct(er):-
> > 
> >     IF xxx AND
> >          yyy AND zzz OR aaa
> >     THEN do something
> > 
> > ... just seems all wrong and difficult to understand.
> 
> not at all
> the split after the operator shows that their is more to that line
> splitting before & the reader could believe that the condition ends there
> 
> PEP 8 is mos definitely correct on this one
> 
> 
> 
> -- 
> According to all the latest reports, there was no truth in any of the
> earlier reports.

I wouldn't call PEP 8 "correct".  I would say that you just simply agree with PEP 8's suggestion.

You guys are spending way too much time fighting over something that is clearly subjective.  Nobody is "correct" here.  There's no right and wrong, just simple preference.

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

#104055

On 04/03/2016 21:14, sohcahtoa82@gmail.com wrote:
> On Friday, March 4, 2016 at 6:03:48 AM UTC-8, alister wrote:
>> On Fri, 04 Mar 2016 10:12:58 +0000, cl wrote:
>>
>>> Steven D'Aprano <steve@pearwood.info> wrote:
>>>> On Fri, 4 Mar 2016 12:23 pm, INADA Naoki wrote:
>>>>
>>>>
>>>>>>
>>>>>> Indeed. I don't understand why, when splitting a condition such as
>>>>>> this,
>>>>>> people tend to put the operator at the end of each line.
>>>>>>
>>>>>>
>>>>> Because PEP8 says:
>>>>>
>>>>>> The preferred place to break around a binary operator is after the
>>>>> operator, not before it. http://pep8.org/#maximum-line-length
>>>>
>>>> PEP 8 is wrong :-)
>>>>
>>> Yes, I agree.  In my mind the logic is:-
>>>
>>>      IF xxx
>>>          AND yyy AND zzz OR aaa
>>>      THEN do something
>>>
>>> The PEP8 correct(er):-
>>>
>>>      IF xxx AND
>>>           yyy AND zzz OR aaa
>>>      THEN do something
>>>
>>> ... just seems all wrong and difficult to understand.
>>
>> not at all
>> the split after the operator shows that their is more to that line
>> splitting before & the reader could believe that the condition ends there
>>
>> PEP 8 is mos definitely correct on this one
>>
>>
>>
>> --
>> According to all the latest reports, there was no truth in any of the
>> earlier reports.
>
> I wouldn't call PEP 8 "correct".  I would say that you just simply agree with PEP 8's suggestion.
>
> You guys are spending way too much time fighting over something that is clearly subjective.  Nobody is "correct" here.  There's no right and wrong, just simple preference.
>

+1

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

Mark Lawrence

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

#104060

On 04/03/16 21:14, sohcahtoa82@gmail.com wrote:
> You guys are spending way too much time fighting over something that is clearly subjective.  Nobody is "correct" here.  There's no right and wrong, just simple preference.

I will take that as a vote +1 that PEP8 is wrong (*). ;)

E.

(*) PEP8 defines a specific format and you are stating that no specific 
format can be considered correct.

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

#104062

On 04/03/2016 23:31, Erik wrote:
> On 04/03/16 21:14, sohcahtoa82@gmail.com wrote:
>> You guys are spending way too much time fighting over something that
>> is clearly subjective.  Nobody is "correct" here.  There's no right
>> and wrong, just simple preference.
>
> I will take that as a vote +1 that PEP8 is wrong (*). ;)
>
> E.
>
> (*) PEP8 defines a specific format and you are stating that no specific
> format can be considered correct.
>

PEP8 is not a standard that must be adhered to under all cicumstances, 
it is only a style guide, hence:-

<quote>
A style guide is about consistency. Consistency with this style guide is 
important. Consistency within a project is more important. Consistency 
within one module or function is the most important.

However, know when to be inconsistent -- sometimes style guide 
recommendations just aren't applicable. When in doubt, use your best 
judgment. Look at other examples and decide what looks best. And don't 
hesitate to ask!
</quote>

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

Mark Lawrence

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

#104063

On 03/04/2016 03:45 PM, Mark Lawrence wrote:

 > PEP8 is not a standard that must be adhered to under all
 > cicumstances, it is only a style guide [...]

Not only that, it's a style guide for code /in the stdlib/.

Make your own style guide for your own projects.  ;)

--
~Ethan~

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

#104066

On 4 March 2016 23:31:43 GMT+00:00, Erik <python@lucidity.plus.com> wrote:
>On 04/03/16 21:14, sohcahtoa82@gmail.com wrote:
>> You guys are spending way too much time fighting over something that
>is clearly subjective.  Nobody is "correct" here.  There's no right and
>wrong, just simple preference.
>
>I will take that as a vote +1 that PEP8 is wrong (*). ;)
>
>E.
>
>(*) PEP8 defines a specific format and you are stating that no specific
>
>format can be considered correct.

Style guides are always going to be considered incorrect by some people, but they should aim more for consistency (the hobgoblin that may be), which is what makes code easier to grok. Stop arguing, start thinking about others who will have to read your code. What is better in your subjective opinion means very little. Having commonly understandable style is what matters, and what style guides help (including PEP8).

Simon
-- 
Sent from Kaiten Mail. Please excuse my brevity.

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

#104070

On Friday, March 4, 2016 at 4:43:57 PM UTC-8, Simon Ward wrote:
> On 4 March 2016 23:31:43 GMT+00:00, Erik <python@lucidity.plus.com> wrote:
> >On 04/03/16 21:14, sohcahtoa82@gmail.com wrote:
> >> You guys are spending way too much time fighting over something that
> >is clearly subjective.  Nobody is "correct" here.  There's no right and
> >wrong, just simple preference.
> >
> >I will take that as a vote +1 that PEP8 is wrong (*). ;)
> >
> >E.
> >
> >(*) PEP8 defines a specific format and you are stating that no specific
> >
> >format can be considered correct.
> 
> Style guides are always going to be considered incorrect by some people, but they should aim more for consistency (the hobgoblin that may be), which is what makes code easier to grok. Stop arguing, start thinking about others who will have to read your code. What is better in your subjective opinion means very little. Having commonly understandable style is what matters, and what style guides help (including PEP8).
> 
> Simon
> -- 
> Sent from Kaiten Mail. Please excuse my brevity.

Arguing whether or not a style guide is "incorrect" is as silly as arguing over whether lima beans are delicious.  I think they're disgusting, but you can't make a statement of fact about the topic.

Style guides are just guides.  They're a suggestion.  You can agree with them or disagree with them.  If I write a guide that dictates that every line of code should only include necessary indentation, a single token, and then a line continuation backslash if necessary, so code looks like this:

x \
= \
5
if \
y \
== \
z:
    print \
    'this is terrible'
    print \
    'but still not incorrect

It would be terrible, still but not incorrect.

This argument about whether binary operators should go on the end of one line or the beginning of the next is the C/C++/C#/Java/etc. fight about braces all over again.  It is entirely subjective, and I find it absolutely ridiculous that so many people are willing to argue until they're blue in the face about it.

If you're doing your own project, do it however you like it and ignore anyone that tells you that you're doing it "wrong".  Not formatting your code to match PEP 8 doesn't make your code formatted wrong, it just means you're choosing not to follow PEP 8 to a T.  Personally, I hate underscores in variable names that aren't constants.  I much prefer myVariableName over my_variable_name.  I think using underscores creates a sort of white space that makes it harder to read.  Do I think that people that use underscores are wrong?  No.  They just have a different opinion.

I just can't understand why so many people get their panties all up in a bunch over how other people choose to format their code.

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

#104073

On 03/04/2016 05:17 PM, sohcahtoa82@gmail.com wrote:

> I just can't understand why so many people get their panties all up in a bunch over how other people choose to format their code.

s/panties/undies/g

;)

--
~Ethan~

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

#104074

sohcahtoa82@gmail.com writes:

> Arguing whether or not a style guide is "incorrect" is as silly as
> arguing over whether lima beans are delicious. I think they're
> disgusting, but you can't make a statement of fact about the topic.

Yet there *are* many relevant facts that bear on the choice of one style
over another.

Objective facts about human capacity to comprehend program text.
Objective facts about the intended semantics of a syntactic structure.
Objective facts about how commonly one style is used in deployed code.

Many objective facts exist that are relevant to the choices in a style
guide. Those facts may be infeasible to *measure* with our limited
access to code bases, and limited resources available for such research.
That doesn't take away from the objective nature of what is actually
factual for a criterion.

So it isn't a pure matter of taste and preference, as some assert.

Yet, when facts are too difficult to ascertain, or when in fact several
styles are equally “good” by whatever objective criteria we might choose
— then deciding that specific matter based on some person's preference
can be quite reasonable, in pursuit of *some* single style which will
allow consistency across a code base.

> Style guides are just guides. They're a suggestion. You can agree with
> them or disagree with them.

Right. The power of such a guide comes from whether, and how, it is
enforced within a particular community.

Don't make the mistake of thinking there are *no* relevant objective
facts to discuss, though.

> I just can't understand why so many people get their panties all up in
> a bunch over how other people choose to format their code.

One factor is that we know (objectively!) that there are many relevant
objective facts to be known; paired with a paucity of actual verifiable
research into those facts available for us to apply to these discussions.

People's personal prejudices start to weigh heavily in those
circumstances.

Yet we can neither say “just do whatever you like” (because too much
inconsistency is a huge cost that is what leads us to write style guides
in the first place), nor can we say “it's all subjective, pick one and
stop arguing” (because that's just not true, there are plenty of
relevant facts that bear on the matter of choosing a style).


What we do need is the wisdom to recognise – when several styles have
good arguments supporting them and no objective facts can help decide
between them – *at what point* should we stop arguing that specific
issue, and just pick a style and stick with it.

Choosing too soon risks dismissing relevant facts that can demonstrate
one style is substantially better than the chosen style.

Choosing too late can allow a community to become weary of ever
discussing style issues again, or of arguing past the point of reason,
or of subverting cohesion by violating the style guide, or resenting it.

All of which loses the unified approach which was the whole point of
working on a style guide in the first place. Wisdom is needed to avoid
that.

I don't have a good general answer.

-- 
 \      “Faith is generally nothing more than the permission religious |
  `\     people give to one another to believe things strongly without |
_o__)      evidence.” —Sam Harris, _Letter to a Christian Nation_ 2006 |
Ben Finney

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

#104076

On 2016-03-04 17:17, sohcahtoa82@gmail.com wrote:
> x \
> = \
> 5
> if \
> y \
> == \
> z:
>     print \
>     'this is terrible'
>     print \
>     'but still not incorrect
> 
> It would be terrible, still but not incorrect.

And has the sociopathic benefit that the diffs make it quite clear
what changed.  None of this
looking-deep-into-lines-to-see-what-changed.

  x \
  = \
  5
  if \
  y \
- != \
+ == \
  z:
      print \
      'this is terrible'
      print \
      'but still not incorrect

Still terrible.  But not quite as useless as a knee-jerk reaction
might suggest.

I actually hacked together a binary-diff something like this,
emitting every hex-formatted byte of each file on its own line, then
diffing the two results.  I could see doing something similar to diff
Python ASTs.

-tkc

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

#104080

thought i should add this here so that people will get to this after
someone decides a standard way to do this :P

look for second if condition in the source code of
subprocess.Popen(*args, **kwargs).communicate

    def communicate(self, input=None, timeout=None):
        """Interact with process: Send data to stdin.  Read data from
        stdout and stderr, until end-of-file is reached.  Wait for
        process to terminate.

        The optional "input" argument should be data to be sent to the
        child process (if self.universal_newlines is True, this should
        be a string; if it is False, "input" should be bytes), or
        None, if no data should be sent to the child.

        communicate() returns a tuple (stdout, stderr).  These will be
        bytes or, if self.universal_newlines was True, a string.
        """

        if self._communication_started and input:
            raise ValueError("Cannot send input after starting communication")

        # Optimization: If we are not worried about timeouts, we haven't
        # started communicating, and we have one or zero pipes, using select()
        # or threads is unnecessary.
        if (timeout is None and not self._communication_started and
            [self.stdin, self.stdout, self.stderr].count(None) >= 2):
            stdout = None
            stderr = None
            if self.stdin:
                self._stdin_write(input)
            elif self.stdout:
                stdout = self.stdout.read()
                self.stdout.close()
            elif self.stderr:
                stderr = self.stderr.read()
            [..... extra code snapped]

ps: Python3.5.1


On Sat, Mar 5, 2016 at 8:19 AM, Tim Chase <python.list@tim.thechases.com> wrote:
> On 2016-03-04 17:17, sohcahtoa82@gmail.com wrote:
>> x \
>> = \
>> 5
>> if \
>> y \
>> == \
>> z:
>>     print \
>>     'this is terrible'
>>     print \
>>     'but still not incorrect
>>
>> It would be terrible, still but not incorrect.
>
> And has the sociopathic benefit that the diffs make it quite clear
> what changed.  None of this
> looking-deep-into-lines-to-see-what-changed.
>
>   x \
>   = \
>   5
>   if \
>   y \
> - != \
> + == \
>   z:
>       print \
>       'this is terrible'
>       print \
>       'but still not incorrect
>
> Still terrible.  But not quite as useless as a knee-jerk reaction
> might suggest.
>
> I actually hacked together a binary-diff something like this,
> emitting every hex-formatted byte of each file on its own line, then
> diffing the two results.  I could see doing something similar to diff
> Python ASTs.
>
> -tkc
>
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
Regards
Srinivas Devaki
Junior (3rd yr) student at Indian School of Mines,(IIT Dhanbad)
Computer Science and Engineering Department
ph: +91 9491 383 249
telegram_id: @eightnoteight

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

#104081

srinivas devaki <mr.eightnoteight@gmail.com> writes:

> thought i should add this here so that people will get to this after
> someone decides a standard way to do this :P

No, you've wasted that effort. If you want a request to be acted on by
those who maintain the official Python source, submit it to the official
Python bug tracker. Here, it will simply be ignored.

-- 
 \     “We live in capitalism. Its power seems inescapable. So did the |
  `\   divine right of kings.” —Ursula K. LeGuin, National Book Awards |
_o__)                                    acceptance speech, 2014-11-19 |
Ben Finney

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

#104067

On 05/03/16 00:23, Simon Ward wrote:
> Style guides are always going to be considered incorrect by some
> people, but they should aim more for consistency (the hobgoblin that
> may be), which is what makes code easier to grok.

So you're saying that it doesn't matter if something is good or bad, as 
long as it's consistently so? I don't agree. Am I not allowed to suggest 
that the style guide is wrong in what it suggests?

FWIW, my issue here is that the language defines that the structure of 
the code is strictly defined by the indentation on the LHS (which is a 
feature I like). This PEP recommends that the structure of the condition 
should be determined by the keywords appearing on the RHS. That, to me, 
is inconsistency. I would prefer it if the PEP suggested that the LHS is 
significant in this case also.

E.

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

#104069

Erik <python@lucidity.plus.com> writes:

> On 05/03/16 00:23, Simon Ward wrote:
> > Style guides are always going to be considered incorrect by some
> > people, but they should aim more for consistency (the hobgoblin that
> > may be), which is what makes code easier to grok.
>
> So you're saying that it doesn't matter if something is good or bad,
> as long as it's consistently so?

That's not my reading of the above. “X more than Y” does not dismiss the
importance of Y.

> Am I not allowed to suggest that the style guide is wrong in what it
> suggests?

Certainly you are allowed. You should not expect that suggestion to be
compelling unless it is accompanied by *factual*, rather than emotive,
argument.

If the advantage is small, you need to accept that the small advantage
will be weighed against the high cost of a long period of inconsistency
with existing, currently-conformant, code. That may be enough to rule
out the option you are suggesting, because we're not starting from a
blank slate of no existing code.

You also need to accept that many choices in a good style guide *will*
be on the basis of choosing among many good options, and thereby exclude
a number of good options from that guide.

It doesn't make those options un-good, it just means that conforming to
the style guide excludes those options.

-- 
 \         “For a sentimentalist is simply one who desires to have the |
  `\    luxury of an emotion without paying for it.” —Oscar Wilde, _De |
_o__)                                                 Profundis_, 1897 |
Ben Finney

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

#104071

Hi Ben,

On 05/03/16 01:05, Ben Finney wrote:
> Certainly you are allowed. You should not expect that suggestion to be
> compelling unless it is accompanied by *factual*, rather than emotive,
> argument.

I thought I had done that. I pointed out that LHS (whitespace) is 
significant when it comes to code structure but RHS seems significant 
when it comes to a condition structure (according to this PEP's 
recommendation). That inconsistency was my argument in the message you 
responded to.

> That may be enough to rule
> out the option you are suggesting, because we're not starting from a
> blank slate of no existing code.

And that's fair enough. I certainly have no desire to argue this until 
everyone agrees with me (which is what some people are accusing me of) - 
I'm just replying to those who keep saying "because PEP8".

I'm done with this thread.

BR,
E.

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

#104084

On Sat, 5 Mar 2016 08:14 am, sohcahtoa82@gmail.com wrote:

> I wouldn't call PEP 8 "correct".  I would say that you just simply agree
> with PEP 8's suggestion.
> 
> You guys are spending way too much time fighting over something that is
> clearly subjective.  Nobody is "correct" here.  There's no right and
> wrong, just simple preference.

Your point is taken, but I think there is an objectively better style. Or at
least there may be an objectively better style. 

Of course, coming up with an objective definition of what is meant
by "better", and performing UI testing to determine which style is better,
is a lot of hard work for marginal gain. It's much more fun to just flame
each other :-)



-- 
Steven

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

#104037

On Fri, 04 Mar 2016 10:23:37 +0900, INADA Naoki wrote:


>>
>> Indeed. I don't understand why, when splitting a condition such as
>> this,
>> people tend to put the operator at the end of each line.
>>
>>
> Because PEP8 says:
> 
>> The preferred place to break around a binary operator is after the
> operator, not before it. http://pep8.org/#maximum-line-length

and that is to make it obvious that there is more to come.




-- 
Nonsense.  Space is blue and birds fly through it.
		-- Heisenberg

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

#104061

alister <alister.ware@ntlworld.com> writes:

> On Fri, 04 Mar 2016 10:23:37 +0900, INADA Naoki wrote:
>
> > Because PEP8 says:
> > 
> >> The preferred place to break around a binary operator is after the
> >> operator, not before it. http://pep8.org/#maximum-line-length
>
> and that is to make it obvious that there is more to come.

That's a good way to express it.

I think there are competing models here:

* When breaking an expression between two lines, put the binary operator
  at the end of the earlier line.

  This makes it obvious what's going on when reading the earlier line.

* When breaking an expression between two lines, put the binary operator
  at the beginning of the later line.

  This makes it obvious what's going on when reading the continuation
  line.

Both have merit. Both models make an almost-identical appeal to
readability.

We can't put the binary operator in multiple places, so have to make a
choice. And, for consistency, we are motivated to set one style and
disallow the other.

Our mistake, I think, is to draw the inference that, because one style
has been chosen, it means the excluded styles do not have merit.

That inference is IMO unfounded. It may be that there are multiple
styles which could be justifiably chosen, and no option clearly superior
to all others.

I think this case – where to put the binary operator when breaking
an expression over a line break – is one where the style guide should
not be taken as advocating on the basis of superiority, but only having
chosen one for consistency.

-- 
 \       “Working out the social politics of who you can trust and why |
  `\      is, quite literally, what a very large part of our brain has |
_o__)                                   evolved to do.” —Douglas Adams |
Ben Finney

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web