On Sat, 5 Mar 2016 08:14 am, sohcahto...@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
srinivas devaki 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
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:
On 2016-03-04 17:17, sohcahto...@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
sohcahto...@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
On 03/04/2016 05:17 PM, sohcahto...@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~
--
https://mail.python.org/mailman/listinfo/python-list
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 c
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 wrote:
> >On 04/03/16 21:14, sohcahto...@gmail.com wrote:
> >> You guys are spending way too much time fighting over something that
> >is clearly subjective. Nobody is "correct" here. There
Erik 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 so
On 03/04/2016 04:30 PM, Ben Finney wrote:> sohcahto...@gmail.com writes:
>> On Friday, March 4, 2016 at 3:41:29 PM UTC-8, Ben Finney wrote:
>>> We can't put the binary operator in multiple places,
>>
>>
>>
>> Who are you, the binary operator police? Watch me!
>>
>> if x == y and \
>> x
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
l
On 4 March 2016 23:31:43 GMT+00:00, Erik wrote:
>On 04/03/16 21:14, sohcahto...@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
sohcahto...@gmail.com writes:
> On Friday, March 4, 2016 at 3:41:29 PM UTC-8, Ben Finney wrote:
> > We can't put the binary operator in multiple places,
>
>
>
> Who are you, the binary operator police? Watch me!
>
> if x == y and \
> x == z and \
> a > b \
> or b > c \
>
On Friday, March 4, 2016 at 3:41:29 PM UTC-8, Ben Finney wrote:
> alister 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.
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~
--
https://mail.pyt
On 04/03/2016 23:31, Erik wrote:
On 04/03/16 21:14, sohcahto...@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 i
alister 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 t
On 04/03/16 21:14, sohcahto...@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 de
On 04/03/2016 21:14, sohcahto...@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 +, cl wrote:
Steven D'Aprano wrote:
On Fri, 4 Mar 2016 12:23 pm, INADA Naoki wrote:
Indeed. I don't understand why, when splitting a condition s
On Friday, March 4, 2016 at 6:03:48 AM UTC-8, alister wrote:
> On Fri, 04 Mar 2016 10:12:58 +, cl wrote:
>
> > Steven D'Aprano wrote:
> >> On Fri, 4 Mar 2016 12:23 pm, INADA Naoki wrote:
> >>
> >>
> >> >>
> >> >> Indeed. I don't understand why, when splitting a condition such as
> >> >> thi
On 03/04/2016 07:25 AM, Ian Kelly wrote:
On Fri, Mar 4, 2016 at 7:03 AM, alister wrote:
On Fri, 04 Mar 2016 10:12:58 +, cl wrote:
Steven D'Aprano 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 te
On Fri, Mar 4, 2016 at 7:03 AM, alister wrote:
> On Fri, 04 Mar 2016 10:12:58 +, cl wrote:
>
>> Steven D'Aprano 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 t
On Fri, 04 Mar 2016 10:12:58 +, cl wrote:
> Steven D'Aprano 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.
>> >>
>> >>
>
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
Steven D'Aprano 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
Steven D'Aprano :
> class C:
> def method(self):
> if (result is None
> or self.some_condition()
> or len(some_sequence) > 100
> or some_other_condition
> or page_count < 5
> ):
> do_processing()
>
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
> operat
On 04/03/16 01:23, 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.
I mean in
>
>
> 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
--
ht
On 04/03/16 00:13, Steven D'Aprano wrote:
class C:
def method(self):
if (result is None
or self.some_condition()
or len(some_sequence) > 100
or some_other_condition
or page_count < 5
):
do_
>
>
> class C:
> def method(self):
> if (result is None
> or self.some_condition()
> or len(some_sequence) > 100
> or some_other_condition
> or page_count < 5
> ):
> do_processing()
>
>
> Looks fine
On Fri, 4 Mar 2016 03:47 am, Marko Rauhamaa wrote:
> John Gordon :
>
>> In <871t7sbkex@elektro.pacujo.net> Marko Rauhamaa
>> writes:
>>
>>> Ethan Furman :
>>
>>> > No, it isn't. Using '\' for line continuation is strongly
>>> > discouraged.
>>
>>> Why would you discourage valid syntax?
>>
>
Rob Gaddi :
> Not ugly, error-prone. The first is purely aestehetic, the second
> actually matters. Let something as simple as a trailing space sneak in
> after your backslash and your meaning changes. Blank line between;
> same thing.
Never been bitten by that.
Now, trying how emacs' indentatio
Marko Rauhamaa wrote:
> John Gordon :
>
>> In <871t7sbkex@elektro.pacujo.net> Marko Rauhamaa
>> writes:
>>
>>> Ethan Furman :
>>
>>> > No, it isn't. Using '\' for line continuation is strongly discouraged.
>>
>>> Why would you discourage valid syntax?
>>
>> Some things that are permissible m
John Gordon :
> In <871t7sbkex@elektro.pacujo.net> Marko Rauhamaa
> writes:
>
>> Ethan Furman :
>
>> > No, it isn't. Using '\' for line continuation is strongly discouraged.
>
>> Why would you discourage valid syntax?
>
> Some things that are permissible may not be desirable.
Line continuat
In <871t7sbkex@elektro.pacujo.net> Marko Rauhamaa writes:
> Ethan Furman :
> > No, it isn't. Using '\' for line continuation is strongly discouraged.
> Why would you discourage valid syntax?
Some things that are permissible may not be desirable.
--
John Gordon A is for
codewiz...@gmail.com wrote:
> On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote:
> >
> > if (some_condition and
> > some_other_condition and
> > some_final_condition):
> > play_bingo()
>
> How about:
>
> continue_playing = (
> some_conditio
On 2016-03-03 08:29, Ben Finney wrote:
> Skip Montanaro writes:
>> Running flake8 over some code which has if statements with
>> multiple conditions like this:
>>
>> if (some_condition and
>> some_other_condition and
>> some_final_condition):
>> play_bingo()
>
> For th
On 03/02/2016 06:33 PM, Chris Angelico wrote:
It's not just name collisions. You should be able to keep in your head
every local name in a section of code. Giving a name to a single-use
expression wastes one of those precious slots in your mind, even if
it's easily and safely unique.
If it's a
On Thu, Mar 3, 2016 at 1:30 PM, Ben Finney wrote:
> If your functions are so long that you fear using a specific name will
> deter you from using it again *in the same scope*, then the name isn't
> descriptive and a better one should be chosen, or the function is too
> large and should be broken i
Steven D'Aprano writes:
> If you only use "continue_playing" in exactly one place, then it
> doesn't deserve a name.
I disagree. If it's complex, then it may still deserve a name.
> > Names are important!
>
> Too important to waste on every single-use expression.
To waste on *every* single-use
On Thu, 3 Mar 2016 11:02 am, Carl Meyer wrote:
> On 03/02/2016 04:54 PM, Chris Angelico wrote:
>> On Thu, Mar 3, 2016 at 10:46 AM, wrote:
>>> On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote:
if (some_condition and
some_other_condition and
On Thu, 3 Mar 2016 09:10 am, Marko Rauhamaa wrote:
> Ethan Furman :
>
>> No, it isn't. Using '\' for line continuation is strongly discouraged.
>
> Why would you discourage valid syntax?
Because it is error-prone and ugly.
This is valid syntax too. Do you write your code like this?
x
(Igor, your “From” field doesn't contain a name for you. Can you put
your name, e.g. “Igor Whateverisyoursurname”, in the “From” field?)
codewiz...@gmail.com writes:
> How about:
>
> continue_playing = (
> some_condition and
> some_other_condition and
> some_final_condition
>
Chris Angelico writes:
> On Thu, Mar 3, 2016 at 10:46 AM, wrote:
>> On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote:
>>>
>>> if (some_condition and
>>> some_other_condition and
>>> some_final_condition):
>>> play_bingo()
>>
>> How about:
>>
>>
On 03/02/2016 04:54 PM, Chris Angelico wrote:
> On Thu, Mar 3, 2016 at 10:46 AM, wrote:
>> On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote:
>>>
>>> if (some_condition and
>>> some_other_condition and
>>> some_final_condition):
>>> play_bingo()
>>
On Thu, Mar 3, 2016 at 10:46 AM, wrote:
> On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote:
>>
>> if (some_condition and
>> some_other_condition and
>> some_final_condition):
>> play_bingo()
>
> How about:
>
> continue_playing = (
> some_co
On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote:
>
> if (some_condition and
> some_other_condition and
> some_final_condition):
> play_bingo()
How about:
continue_playing = (
some_condition and
some_other_condition and
some_fi
On Thu, Mar 3, 2016 at 9:10 AM, Marko Rauhamaa wrote:
> Ethan Furman :
>
>> No, it isn't. Using '\' for line continuation is strongly discouraged.
>
> Why would you discourage valid syntax?
>
Isn't that exactly the point of style guides? They stipulate/encourage
a particular subset of valid synt
On 03/02/2016 02:44 PM, Skip Montanaro wrote:
I don't know. Maybe I need to ask the flake8 author about his
rationale for this message. It seems to me from my experience with the
language that this particular message is going against pretty common
practice. Does vim's Python mode exhibit similar
On 03/02/2016 02:10 PM, Marko Rauhamaa wrote:
Ethan Furman :
No, it isn't. Using '\' for line continuation is strongly discouraged.
Why would you discourage valid syntax?
1) It's ugly
2) Any non-newline whitespace after the '\' and you don't have line
continuation any more, and no visib
Thanks for the replies, folks. I'll provide a single response:
1. Using backslash to continue... When I first started using Python in
the mid-90s I don't recall that parenthesized expressions could be
continued across lines (at least, not in all contexts), so the
backslash was required. I believe
Ethan Furman :
> No, it isn't. Using '\' for line continuation is strongly discouraged.
Why would you discourage valid syntax?
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On 03/02/2016 12:50 PM, Marko Rauhamaa wrote:
Skip Montanaro queried:
Running flake8 over some code which has if statements with multiple
conditions like this:
if (some_condition and
some_other_condition and
some_final_condition):
play_bingo()
[...]
is there a
Skip Montanaro writes:
> Running flake8 over some code which has if statements with multiple
> conditions like this:
>
> if (some_condition and
> some_other_condition and
> some_final_condition):
> play_bingo()
>
> the tool complains that the indentation of the conditi
Skip Montanaro wrote:
> Running flake8 over some code which has if statements with multiple
> conditions like this:
>
> if (some_condition and
> some_other_condition and
> some_final_condition):
> play_bingo()
>
> the tool complains that the indentation of the conditi
On 3/2/2016 21:43, Skip Montanaro wrote:
Running flake8 over some code which has if statements with multiple
conditions like this:
if (some_condition and
some_other_condition and
some_final_condition):
play_bingo()
the tool complains that the indentation of the c
Skip Montanaro :
> Running flake8 over some code which has if statements with multiple
> conditions like this:
>
> if (some_condition and
> some_other_condition and
> some_final_condition):
> play_bingo()
> [...]
>
> is there a better way to break lines I'm missing whic
Running flake8 over some code which has if statements with multiple
conditions like this:
if (some_condition and
some_other_condition and
some_final_condition):
play_bingo()
the tool complains that the indentation of the conditions is the same
as the next block. In th
59 matches
Mail list logo
