How would I best type the following:

if long_condition1 or (long_condition2 and long_condition3):

Without making a complete, unreadable mess.

some_name = long_conditionn # bool

will not work, because I can't evaluate long_condition2 if 1 is true.

 -Shay

Post a reply to this message

Shay escreveu:
> How would I best type the following:
> 
> if long_condition1 or (long_condition2 and long_condition3):
> 
> Without making a complete, unreadable mess.
> 
> some_name = long_conditionn # bool
> 
> will not work, because I can't evaluate long_condition2 if 1 is true.

what's the problem people have with parentheses?

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

On Wed, 17 Aug 2011 14:12:02 -0300, nemesis wrote:

> Shay escreveu:
>> How would I best type the following:
>> 
>> if long_condition1 or (long_condition2 and long_condition3):
>> 
>> Without making a complete, unreadable mess.
>> 
>> some_name = long_conditionn # bool
>> 
>> will not work, because I can't evaluate long_condition2 if 1 is true.
> 
> what's the problem people have with parentheses?


No problem with parenthesis. But Python is a little funny about spacing.

A = [0, 1]
B = [0, 1]
C = [0, 1]
D = [0, 1]
List = [A, B, C, D]

if (
	some_funk(x for x in List) or
	(
		some_other_func(x for x in List) and
		a_third_func(x for x in List))):


That's legal(ish), but now I'm screwed with my indentation.


if (
	some_funk(x for x in List) or
	(some_other_func(x for x in List) and
	a_third_func(x for x in List))):
	print("execute code here")

How I ended up going, but it's still a little hairy to read.

Then I though about it a bit more and went with:

my_bool = (
	some_funk(x for x in List) or
	(
		some_other_func(x for x in List) and
		a_third_func(x for x in List)))
if my_bool:
	print("execute code here")


 -Shay

Post a reply to this message

Hmm.

     y = (x for x in List)
     if some_funk(y) or some_other_func(y) and a_third_func(y):

Why would you even want to calculate (x for x in List) three times?

Or am I misunderstanding "x for x in List"? Isn't that a list comprehension 
in Python?

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/17/2011 7:45 PM, Darren New wrote:
> Hmm.
>
> y = (x for x in List)
> if some_funk(y) or some_other_func(y) and a_third_func(y):
>
> Why would you even want to calculate (x for x in List) three times?
>
> Or am I misunderstanding "x for x in List"? Isn't that a list
> comprehension in Python?
>

It's not a list comprehension, but rather creates a generator object 
iterating over the items in List.  The list comprehension would use 
square brackets [x for x in List].  I still don't understand why it's 
being used here though, since it seems like List could just be passed in 
directly since it's obviously iterable too (unless the called functions 
are doing something odd, which maybe is the case here).

Post a reply to this message

On Wed, 17 Aug 2011 19:45:42 -0700, Darren New wrote:

> Hmm.
> 
>      y = (x for x in List)
>      if some_funk(y) or some_other_func(y) and a_third_func(y):
> 
> Why would you even want to calculate (x for x in List) three times?
> 
> Or am I misunderstanding "x for x in List"? Isn't that a list
> comprehension in Python?


That's just a BS example. Just a style question. Here's a real example of 
what I'm trying to do:

# A special case for 2-dimensional vectors
# with acute ccw angles
A = [[1, 2, 0], [2, 3, 4], [4, 8, 6]]

bool_a = len(A[0]) == 2
bool_b = min([A[2] == x[2] for x in A[1:])
bool_c = ccw_angle(*A) < pi

ccw_angle is my own function
bool_b will not work if bool_a is true

if bool_a or bool_b:
	if bool_c:

would mean code repetition where:
a or b is true and c is false
neither a nor b is true

So, maybe I do have the best answer with:
bool_ = long conditions
if bool_:

Post a reply to this message

On 8/19/2011 13:04, Shay wrote:
> bool_a = len(A[0]) == 2
> bool_b = min([A[2] == x[2] for x in A[1:])
> bool_c = ccw_angle(*A)<  pi
>
> bool_b will not work if bool_a is true

bool_b = bool_a ? min(...) : false

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On Fri, 19 Aug 2011 13:49:01 -0700, Darren New wrote:

> On 8/19/2011 13:04, Shay wrote:
>> bool_a = len(A[0]) == 2
>> bool_b = min([A[2] == x[2] for x in A[1:]) bool_c = ccw_angle(*A)<  pi
>>
>> bool_b will not work if bool_a is true
> 
> bool_b = bool_a ? min(...) : false

Beautiful, but that doesn't seem to be valid Python. However, a bit of 
guess-work reveals that:

bool_b = False if bool_a else min(...)

does work. So, I learned something there.


Thanks.
 -Shay

Post a reply to this message

On 8/20/2011 22:52, Shay wrote:
> On Fri, 19 Aug 2011 13:49:01 -0700, Darren New wrote:
>
>> On 8/19/2011 13:04, Shay wrote:
>>> bool_a = len(A[0]) == 2
>>> bool_b = min([A[2] == x[2] for x in A[1:]) bool_c = ccw_angle(*A)<   pi
>>>
>>> bool_b will not work if bool_a is true
>>
>> bool_b = bool_a ? min(...) : false
>
> Beautiful, but that doesn't seem to be valid Python.

OK. I had assumed python had that operator. It's the same as

if bool_a then bool_b = min(...) else bool_b = false;

> bool_b = False if bool_a else min(...)
> does work. So, I learned something there.

I think you *might* have the condition reversed on that. That looks like 
it's saying you don't evaluate bool_b if bool_a is true.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On Sun, 21 Aug 2011 08:00:28 -0700, Darren New wrote:

> On 8/20/2011 22:52, Shay wrote:
>> On Fri, 19 Aug 2011 13:49:01 -0700, Darren New wrote:
>>
>>> On 8/19/2011 13:04, Shay wrote:
>>>> bool_a = len(A[0]) == 2
>>>> bool_b = min([A[2] == x[2] for x in A[1:]) bool_c = ccw_angle(*A)<  
>>>> pi
>>>>
>>>> bool_b will not work if bool_a is true
>>>
>>> bool_b = bool_a ? min(...) : false
>>
>> Beautiful, but that doesn't seem to be valid Python.
> 
> OK. I had assumed python had that operator. It's the same as
> 
> if bool_a then bool_b = min(...) else bool_b = false;
> 
>> bool_b = False if bool_a else min(...) does work. So, I learned
>> something there.
> 
> I think you *might* have the condition reversed on that. That looks like
> it's saying you don't evaluate bool_b if bool_a is true.

That's what I want. I mistyped a portion of my example

bool_b = min([A[2] == x[2] for x in A[1:])

should have been

bool_b = min([A[0][2] == x[2] for x in A[1:])

bool_b tests if all of the [2]s are equal. If bool_a is true, there are 
no [2]s.

Thanks for the help.

 -Shay

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> bool_b = bool_a ? min(...) : false

  That seems to have redundancy. How about:

bool_b = bool_a || min(...);

-- 
                                                          - Warp

Post a reply to this message

On 8/22/2011 8:04, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>> bool_b = bool_a ? min(...) : false
>
>    That seems to have redundancy. How about:
>
> bool_b = bool_a || min(...);
>

More efficient perhaps, but less readable IMO. You don't really want to set 
bool_b to the value of bool_a, so this I would consider misleading. There's 
an implication that the value of bool_a propagates, whereas in actuality 
it's more a gating value.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> On 8/22/2011 8:04, Warp wrote:
> > Darren New<dne### [at] sanrrcom>  wrote:
> >> bool_b = bool_a ? min(...) : false
> >
> >    That seems to have redundancy. How about:
> >
> > bool_b = bool_a || min(...);
> >

  Btw, I made a mistake above. Obviously it should have been:

bool_b = bool_a && min(...);

  (Yes, I understand the irony that you not catching this mistake is a
tell-tale sign of the obfuscatory nature of the expression. I still prefer
it, though.)

> More efficient perhaps, but less readable IMO. You don't really want to set 
> bool_b to the value of bool_a, so this I would consider misleading. There's 
> an implication that the value of bool_a propagates, whereas in actuality 
> it's more a gating value.

  You are not setting bool_b the value of bool_a. You are making a boolean
'and', and assigning the result of that to bool_b. The shortcut evaluation
of operator && is being (ab)used here to avoid evaluating the min(...)
expression in case bool_a is false. The advantage of this is that it
avoids the redundancy of the "else false" branch. (It's a bit like that
annoying "else break;" at the end of a loop, only in this case it's easily
avoidable.)

  This is, btw, a common tactic used in unix shell scripts. There the
&& operator can be used for a very similar purpose: If the command at the
left hand side succeeds, the command at the right hand side is executed.
The value of the expression is that of the first command that didn't
succeed, or success if they all succeeded.

  This means that rather than having to do something like

    if [ command1 ]; then if [ command2 ]; then command3; fi; fi

you can do it like:

    command1 && command2 && command3

  This is handy to execute several commands in succession, but have the
entire thing immediately stop if any of the commands fails. (This in
contrast with "command1; command2; command3" which will not stop if any
of those fails.)

-- 
                                                          - Warp

Post a reply to this message

On 8/26/2011 7:48, Warp wrote:
>    You are not setting bool_b the value of bool_a.

And that's exactly my complaint. The value of bool_b is dependent on bool_a, 
but not really assigned from it. I'm sure you see what I mean.

> You are making a boolean
> 'and', and assigning the result of that to bool_b.

But when the first expression indicates the second can't be evaluated, 
there's no reason to assign the first expression to bool_b, semantically 
speaking. I.e., it looks to me like it's tying the two too closely.

> avoids the redundancy of the "else false" branch.

True. On the other hand, the value of bool_b is never used if bool_a is 
wrong, so unless your language insists it be assigned before use and doesn't 
initialize it for you, there's no real reason to assign to it at all if 
bool_a indicates the value is invalid.

> (It's a bit like that
> annoying "else break;" at the end of a loop, only in this case it's easily
> avoidable.)

I can see your point.

>    This is, btw, a common tactic used in unix shell scripts.

Yeah, but IME it's usually used *only* to short circut the evaluation, not 
to actually use the result. YMMV.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> On 8/26/2011 7:48, Warp wrote:
> >    You are not setting bool_b the value of bool_a.

> And that's exactly my complaint. The value of bool_b is dependent on bool_a, 
> but not really assigned from it. I'm sure you see what I mean.

  Not really.

> > You are making a boolean
> > 'and', and assigning the result of that to bool_b.

> But when the first expression indicates the second can't be evaluated, 
> there's no reason to assign the first expression to bool_b, semantically 
> speaking. I.e., it looks to me like it's tying the two too closely.

  bool_a is not being assigned to bool_b. The result of the expression
"something && something_else" is being assigned to bool_b.

  I don't even understand what is it that you don't like about this.

> >    This is, btw, a common tactic used in unix shell scripts.

> Yeah, but IME it's usually used *only* to short circut the evaluation, not 
> to actually use the result. YMMV.

  It may be *common* for the result to be discarded, but it's perfectly
possible to take the result into account for subsequent decisions. The
advantage of using a sequence of commands separated by && is that you
don't need to put an 'if' after each of the commands, if you want to
react to one of them failing. You only need to use one 'if' to catch any
of them failing.

-- 
                                                          - Warp

Post a reply to this message

On 8/27/2011 7:14, Warp wrote:
>    bool_a is not being assigned to bool_b. The result of the expression
> "something&&  something_else" is being assigned to bool_b.
>
>    I don't even understand what is it that you don't like about this.

If bool_a is false, then bool_a is being assigned to bool_b. This implies in 
a vague sense that bool_b is false when bool_a is false. In reality, bool_b 
is *undefined* when bool_a is false. One assigns it "false" not because 
bool_a is false, but because one must assign something in that statement, 
and it doesn't matter what gets assigned.

In other words, in a language that supported tri-value logic (like PHP, 
perhaps), I'd say
   bool_b = bool_a ? min(...) : undefined
to make it clear.

>    It may be *common* for the result to be discarded, but it's perfectly
> possible to take the result into account for subsequent decisions. The
> advantage of using a sequence of commands separated by&&  is that you
> don't need to put an 'if' after each of the commands, if you want to
> react to one of them failing. You only need to use one 'if' to catch any
> of them failing.

Sure. And if the person wrote
   bool_a = big_long_expression_one(alpha,beta,gamma)
   bool_b = big_long_expression_one(alpha,beta,gamma) && min(...)
then I would agree that would be the right expression.

Again, it's a matter of taste. Written with the boolean, I'd have to stop 
and look at the rest of the code to see if, for example, there's a
    bool_b == bool_a
kind of expression somewhere later to try to understand what the bools meant.

Of course, picking better names for the bools would obviate the entire 
debate. :-)

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message