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

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

1 > 0 == True -> False

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

Contents

  1 > 0 == True -> False Thibault Langlois <thibault.langlois@gmail.com> - 2014-01-30 03:36 -0800
    Re: 1 > 0 == True -> False Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2014-01-30 12:44 +0100
    Re: 1 > 0 == True -> False Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-01-30 13:46 +0200
      Re: 1 > 0 == True -> False Peter Otten <__peter__@web.de> - 2014-01-30 13:04 +0100
        Re: 1 > 0 == True -> False Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-01-30 14:08 +0200
    Re:1 > 0 == True -> False Dave Angel <davea@davea.name> - 2014-01-30 07:49 -0500
      Re: 1 > 0 == True -> False Thibault Langlois <thibault.langlois@gmail.com> - 2014-01-30 05:40 -0800
        Re: 1 > 0 == True -> False Chris Angelico <rosuav@gmail.com> - 2014-01-31 00:55 +1100
        Re: 1 > 0 == True -> False Roy Smith <roy@panix.com> - 2014-01-30 09:08 -0500
          Re: 1 > 0 == True -> False Chris Angelico <rosuav@gmail.com> - 2014-01-31 01:18 +1100
            Re: 1 > 0 == True -> False Roy Smith <roy@panix.com> - 2014-01-30 09:49 -0500
              Re: 1 > 0 == True -> False Chris Angelico <rosuav@gmail.com> - 2014-01-31 02:02 +1100
          Re: 1 > 0 == True -> False Devin Jeanpierre <jeanpierreda@gmail.com> - 2014-01-30 06:41 -0800
          Re: 1 > 0 == True -> False Thibault Langlois <thibault.langlois@gmail.com> - 2014-01-30 06:46 -0800
            Re: 1 > 0 == True -> False Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-30 17:42 +0000
          Re: 1 > 0 == True -> False Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-01-30 16:56 +0200
            Re: 1 > 0 == True -> False Roy Smith <roy@panix.com> - 2014-01-30 10:46 -0800
              Re: 1 > 0 == True -> False Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-01-30 22:14 +0200
                Re: 1 > 0 == True -> False Chris Angelico <rosuav@gmail.com> - 2014-01-31 07:25 +1100
          Re: 1 > 0 == True -> False Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-30 15:09 +0000
            Re: 1 > 0 == True -> False Rustom Mody <rustompmody@gmail.com> - 2014-01-30 07:34 -0800
            Re: 1 > 0 == True -> False Roy Smith <roy@panix.com> - 2014-01-30 10:53 -0800
              Re: 1 > 0 == True -> False Rustom Mody <rustompmody@gmail.com> - 2014-01-30 19:33 -0800
            Re: 1 > 0 == True -> False Roy Smith <roy@panix.com> - 2014-01-30 10:56 -0800
              Re: 1 > 0 == True -> False Chris Angelico <rosuav@gmail.com> - 2014-01-31 06:03 +1100
                Re: 1 > 0 == True -> False Roy Smith <roy@panix.com> - 2014-01-30 14:09 -0800
                  Re: 1 > 0 == True -> False Chris Angelico <rosuav@gmail.com> - 2014-01-31 09:29 +1100
              Re: 1 > 0 == True -> False Ethan Furman <ethan@stoneleaf.us> - 2014-01-30 11:22 -0800
              Re: 1 > 0 == True -> False Chris Angelico <rosuav@gmail.com> - 2014-01-31 06:48 +1100
      Re: 1 > 0 == True -> False Rotwang <sg552@hotmail.co.uk> - 2014-01-30 19:25 +0000
        Re: 1 > 0 == True -> False Dave Angel <davea@davea.name> - 2014-01-30 15:08 -0500
        Re: 1 > 0 == True -> False Chris Angelico <rosuav@gmail.com> - 2014-01-31 07:15 +1100
        Re: 1 > 0 == True -> False Ian Kelly <ian.g.kelly@gmail.com> - 2014-01-30 13:28 -0700
        Re: 1 > 0 == True -> False Chris Angelico <rosuav@gmail.com> - 2014-01-31 07:38 +1100
        Re: 1 > 0 == True -> False Ian Kelly <ian.g.kelly@gmail.com> - 2014-01-30 14:17 -0700
        Re: 1 > 0 == True -> False Chris Angelico <rosuav@gmail.com> - 2014-01-31 08:31 +1100
        Re: 1 > 0 == True -> False Joshua Landau <joshua@landau.ws> - 2014-01-30 23:36 +0000
          Re: 1 > 0 == True -> False Rotwang <sg552@hotmail.co.uk> - 2014-01-31 00:10 +0000
            Removal of iterable unpacking in function calls (was: 1 > 0 == True -> False) Ben Finney <ben+python@benfinney.id.au> - 2014-01-31 11:21 +1100
              Re: Removal of iterable unpacking in function calls Rotwang <sg552@hotmail.co.uk> - 2014-01-31 00:32 +0000
            Re: 1 > 0 == True -> False Joshua Landau <joshua@landau.ws> - 2014-01-31 00:32 +0000
        Re: 1 > 0 == True -> False Chris Angelico <rosuav@gmail.com> - 2014-01-31 11:01 +1100

Page 1 of 3  [1] 2 3  Next page →

#64981 — 1 > 0 == True -> False

Hello,

$ python
Python 2.7.4 (default, Sep 26 2013, 03:20:26) 
[GCC 4.7.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 > 0 == True
False
>>> (1 > 0) == True
True
>>> 1 > (0 == True)
True
>>>

What am I missing here ?

T.

[toc] | [next] | [standalone]

#64982

Thibault Langlois schrieb:
>>>> 1 > 0 == True
> False
> What am I missing here ?

This, perhaps:
http://www.primozic.net/nl/chaining-comparison-operators-in-python/

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

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

#64983

Thibault Langlois writes:

> Hello,
> 
> $ python
> Python 2.7.4 (default, Sep 26 2013, 03:20:26) 
> [GCC 4.7.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> 1 > 0 == True
> False
> >>> (1 > 0) == True
> True
> >>> 1 > (0 == True)
> True
> >>>
> 
> What am I missing here ?

One or both of the following:

   >>> 0 == True
   False
   >>> True and False
   False
   >>> 1 > 0
   True

Or the fact that (1 > 0 == True) means ((1 > 0) and (0 == True)),
where each expression in such a chain is evaluated once, though in
this case it really does not matter since 0 is a literal.

Hm, I don't know if the evaluation short-circuits. I think not, but
I've never needed to know, and I don't need to know now.

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

#64987

Jussi Piitulainen wrote:

> Thibault Langlois writes:
> 
>> Hello,
>> 
>> $ python
>> Python 2.7.4 (default, Sep 26 2013, 03:20:26)
>> [GCC 4.7.3] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> 1 > 0 == True
>> False
>> >>> (1 > 0) == True
>> True
>> >>> 1 > (0 == True)
>> True
>> >>>
>> 
>> What am I missing here ?
> 
> One or both of the following:
> 
>    >>> 0 == True
>    False
>    >>> True and False
>    False
>    >>> 1 > 0
>    True
> 
> Or the fact that (1 > 0 == True) means ((1 > 0) and (0 == True)),
> where each expression in such a chain is evaluated once, though in
> this case it really does not matter since 0 is a literal.
> 
> Hm, I don't know if the evaluation short-circuits. I think not, but
> I've never needed to know, and I don't need to know now.

It is easy to check though:

>>> def zero():
...     print("zero")
...     return 0
... 
>>> def one():
...     print("one")
...     return 1
... 
>>> def true():
...     print("true")
...     return True
... 
>>> one() > zero() == true()
one
zero
true
False
>>> zero() > one() == true()
zero
one
False

So yes, evaluation does short-curcuit.

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

#64988

Peter Otten writes:

> Jussi Piitulainen wrote:
> 
> > Thibault Langlois writes:
> > 
> >> Hello,
> >> 
> >> $ python
> >> Python 2.7.4 (default, Sep 26 2013, 03:20:26)
> >> [GCC 4.7.3] on linux2
> >> Type "help", "copyright", "credits" or "license" for more information.
> >> >>> 1 > 0 == True
> >> False
> >> >>> (1 > 0) == True
> >> True
> >> >>> 1 > (0 == True)
> >> True
> >> >>>
> >> 
> >> What am I missing here ?
> > 
> > One or both of the following:
> > 
> >    >>> 0 == True
> >    False
> >    >>> True and False
> >    False
> >    >>> 1 > 0
> >    True
> > 
> > Or the fact that (1 > 0 == True) means ((1 > 0) and (0 == True)),
> > where each expression in such a chain is evaluated once, though in
> > this case it really does not matter since 0 is a literal.
> > 
> > Hm, I don't know if the evaluation short-circuits. I think not, but
> > I've never needed to know, and I don't need to know now.
> 
> It is easy to check though:
> 
> >>> def zero():
> ...     print("zero")
> ...     return 0
> ... 
> >>> def one():
> ...     print("one")
> ...     return 1
> ... 
> >>> def true():
> ...     print("true")
> ...     return True
> ... 
> >>> one() > zero() == true()
> one
> zero
> true
> False
> >>> zero() > one() == true()
> zero
> one
> False
> 
> So yes, evaluation does short-curcuit.

Now I'm experiencing a mild form of information overload. Thanks
anyway :) My guess was wrong.

Now that I think of it, I've implemented a parser and evaluator once
with this kind of chaining, and it may well have short-circuited.

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

#64991

 Thibault Langlois <thibault.langlois@gmail.com> Wrote in message:
> Hello,
> 
> $ python
> Python 2.7.4 (default, Sep 26 2013, 03:20:26) 
> [GCC 4.7.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> 1 > 0 == True
> False
>>>> (1 > 0) == True
> True
>>>> 1 > (0 == True)
> True
>>>>
> 
> What am I missing here ?
> 
> T.
> 

You tell us. You supply only half the question,  what it does,
 without saying what you expected or needed. 

I expect you're either confused about comparison chaining or about
 what happens when you compare objects of different types.
 

Doing an ordered comparison between two types is undefined by
 default, and not guaranteed to even give the same result between
 builds.  So the following may give different results on your
 2.7.4 than on mine.
        5 < "abc"

Python 3 fixes that by throwing an exception.  TypeError:
 unorderable types

This should solve it, since the first and third expression would
 seem to be undefined. Unfortunately there's yet another wrinkle.
 

For hysterical reasons,  True and False are instances of class
 bool, which is derived from int. So for comparison purposes
 False==0 and True==1. But in my opinion,  you should never take
 advantage of this, except when entering obfuscation
 contests.


-- 
DaveA

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

#64999

On Thursday, January 30, 2014 12:49:19 PM UTC, Dave Angel wrote:
> Thibault Langlois <thibault.langlois@gmail.com> Wrote in message:
> 
> > Hello,
> 
> > 
> 
> > $ python
> 
> > Python 2.7.4 (default, Sep 26 2013, 03:20:26) 
> 
> > [GCC 4.7.3] on linux2
> 
> > Type "help", "copyright", "credits" or "license" for more information.
> 
> >>>> 1 > 0 == True
> 
> > False
> 
> >>>> (1 > 0) == True
> 
> > True
> 
> >>>> 1 > (0 == True)
> 
> > True
> 
> >>>>
> 
> > 
> 
> > What am I missing here ?
> 
> > 
> 
> > T.
> 
> > 
> 
> 
> 
> You tell us. You supply only half the question,  what it does,
> 
>  without saying what you expected or needed. 
> 
> 
> 
> I expect you're either confused about comparison chaining or about
> 
>  what happens when you compare objects of different types.
> 
>  
> 
> 
> 
> Doing an ordered comparison between two types is undefined by
> 
>  default, and not guaranteed to even give the same result between
> 
>  builds.  So the following may give different results on your
> 
>  2.7.4 than on mine.
> 
>         5 < "abc"
> 
> 
> 
> Python 3 fixes that by throwing an exception.  TypeError:
> 
>  unorderable types
> 
> 
> 
> This should solve it, since the first and third expression would
> 
>  seem to be undefined. Unfortunately there's yet another wrinkle.
> 
>  
> 
> 
> 
> For hysterical reasons,  True and False are instances of class
> 
>  bool, which is derived from int. So for comparison purposes
> 
>  False==0 and True==1. But in my opinion,  you should never take
> 
>  advantage of this, except when entering obfuscation
> 
>  contests.
> 
> 
> 
> 
> 
> -- 
> 
> DaveA

You are right. I should have given some context.
I am looking at this from the perspective of the teacher that has to explain idiosyncrasies of the language to inexperienced students.
There are two aspects in this example. 
1. the equivalence of True/False with integers 1/0 which have pro and cons.
2. the chaining rules of operators. I agree that it may make sense in some cases like x > y > z but when operators are mixed it leads to counter intuitive cases as the one I pointed out.

The recommendations to student are 1) do not assume True == 1 and do not use operator chaining.

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

#65002

On Fri, Jan 31, 2014 at 12:40 AM, Thibault Langlois
<thibault.langlois@gmail.com> wrote:
> The recommendations to student are 1) do not assume True == 1 and do not use operator chaining.

Not "do not use", but "do not misuse". Python's operator chaining is
awesome for bounds checking:

if 3 < x < 20:
  print("x is between 3 and 20, exclusive")

You can even, since it short-circuits, do crazy stuff like:

x = random.randrange(30)
if int(input("Min: ")) < x < int(input("Max: ")):
    print("It's within those bounds.")

It won't ask for a maximum if it's already failed to be within the
minimum. (Okay, don't do this one. Not good code. Heh.)

But don't use operator chaining when you don't mean it to behave that
way. That's all!

ChrisA

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

#65005

In article <3dcdc95d-5e30-46d3-b558-afedf9723c7c@googlegroups.com>,
 Thibault Langlois <thibault.langlois@gmail.com> wrote:

> You are right. I should have given some context.
> I am looking at this from the perspective of the teacher that has to explain 
> idiosyncrasies of the language to inexperienced students.
> There are two aspects in this example. 
> 1. the equivalence of True/False with integers 1/0 which have pro and cons.
> 2. the chaining rules of operators. I agree that it may make sense in some 
> cases like x > y > z but when operators are mixed it leads to counter 
> intuitive cases as the one I pointed out.
> 
> The recommendations to student are 1) do not assume True == 1 and do not use 
> operator chaining.

Better than that, do what I do.

1) Assume that you don't have the full operator precedence table 
memorized and just parenthesize everything.

2) In cases where the expression is so simple, you couldn't possibly be 
wrong, see rule #1.

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

#65009

On Fri, Jan 31, 2014 at 1:08 AM, Roy Smith <roy@panix.com> wrote:
> Better than that, do what I do.
>
> 1) Assume that you don't have the full operator precedence table
> memorized and just parenthesize everything.

Or:

1a) Assume that you don't have the full operator precedence table
memorized and just look it up, for whichever language you're working
with today. :)

Usually the precedence table will also remind me of operator chaining,
and whether the integer division and modulo operators are backward
(compare REXX and Python with their % and // operators), and anything
else that needs concern.

ChrisA

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

#65014

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

> On Fri, Jan 31, 2014 at 1:08 AM, Roy Smith <roy@panix.com> wrote:
> > Better than that, do what I do.
> >
> > 1) Assume that you don't have the full operator precedence table
> > memorized and just parenthesize everything.
> 
> Or:
> 
> 1a) Assume that you don't have the full operator precedence table
> memorized and just look it up, for whichever language you're working
> with today. :)

It's faster to just stick in some extra parens.  Not to mention that it 
makes the code more clear for everybody reading it later.

Operator precedence is a tricky thing.  In part, because it's somewhat 
arbitrary, and in part because it changes from language to language.  
Using "extra" parens to make my meaning clear (to both the compiler and 
other humans who read the code in the future) is a simple technique 
which works in all languages.

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

#65016

On Fri, Jan 31, 2014 at 1:49 AM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.6143.1391091519.18130.python-list@python.org>,
>  Chris Angelico <rosuav@gmail.com> wrote:
>
>> On Fri, Jan 31, 2014 at 1:08 AM, Roy Smith <roy@panix.com> wrote:
>> > Better than that, do what I do.
>> >
>> > 1) Assume that you don't have the full operator precedence table
>> > memorized and just parenthesize everything.
>>
>> Or:
>>
>> 1a) Assume that you don't have the full operator precedence table
>> memorized and just look it up, for whichever language you're working
>> with today. :)
>
> It's faster to just stick in some extra parens.  Not to mention that it
> makes the code more clear for everybody reading it later.

That won't protect you from getting modulo and truncating-division mixed up. :)

> Operator precedence is a tricky thing.  In part, because it's somewhat
> arbitrary, and in part because it changes from language to language.
> Using "extra" parens to make my meaning clear (to both the compiler and
> other humans who read the code in the future) is a simple technique
> which works in all languages.

It's not arbitrary, but there are differences from language to
language. Yes, parens can help, but I would strongly advocate NOT
using them where it's utterly unambiguous:

x = (2*3)+4 # Pointless!

Whether your language works with * before + (the sane way, doing what
we expect from algebra) or purely left to right (the insane way, but
some languages do do that), the parens are superfluous. Don't use 'em!

But if you work with both PHP and any other language that has a ?:
operator, parenthesizing any nesting of them will avoid a PHP
stupidity. Not that that's really any sort of argument here, though.

ChrisA

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

#65012

On Thu, Jan 30, 2014 at 6:08 AM, Roy Smith <roy@panix.com> wrote:
> 1) Assume that you don't have the full operator precedence table
> memorized and just parenthesize everything.
>
> 2) In cases where the expression is so simple, you couldn't possibly be
> wrong, see rule #1.

Also, assume you don't have the function definition syntax memorized,
and just define functions. And assume you don't know Python, so just
hire someone else to write your code instead.

-- Devin

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

#65013

On Thursday, January 30, 2014 2:08:58 PM UTC, Roy Smith wrote:
> In article <3dcdc95d-5e30-46d3-b558-afedf9723c7c@googlegroups.com>,
> 
>  Thibault Langlois <thibault.langlois@gmail.com> wrote:
> 
> 
> 
> > You are right. I should have given some context.
> 
> > I am looking at this from the perspective of the teacher that has to explain 
> 
> > idiosyncrasies of the language to inexperienced students.
> 
> > There are two aspects in this example. 
> 
> > 1. the equivalence of True/False with integers 1/0 which have pro and cons.
> 
> > 2. the chaining rules of operators. I agree that it may make sense in some 
> 
> > cases like x > y > z but when operators are mixed it leads to counter 
> 
> > intuitive cases as the one I pointed out.
> 
> > 
> 
> > The recommendations to student are 1) do not assume True == 1 and do not use 
> 
> > operator chaining.
> 
> 
> 
> Better than that, do what I do.
> 
> 
> 
> 1) Assume that you don't have the full operator precedence table 
> 
> memorized and just parenthesize everything.
> 
> 
> 
> 2) In cases where the expression is so simple, you couldn't possibly be 
> 
> wrong, see rule #1.

Agreed !

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

#65030

On 30/01/2014 14:46, Thibault Langlois wrote:
> On Thursday, January 30, 2014 2:08:58 PM UTC, Roy Smith wrote:
>> In article <3dcdc95d-5e30-46d3-b558-afedf9723c7c@googlegroups.com>,
>>
>>   Thibault Langlois <thibault.langlois@gmail.com> wrote:
>>
>>
>>
>>> You are right. I should have given some context.
>>
>>> I am looking at this from the perspective of the teacher that has to explain
>>
>>> idiosyncrasies of the language to inexperienced students.
>>
>>> There are two aspects in this example.
>>
>>> 1. the equivalence of True/False with integers 1/0 which have pro and cons.
>>
>>> 2. the chaining rules of operators. I agree that it may make sense in some
>>
>>> cases like x > y > z but when operators are mixed it leads to counter
>>
>>> intuitive cases as the one I pointed out.
>>
>>>
>>
>>> The recommendations to student are 1) do not assume True == 1 and do not use
>>
>>> operator chaining.
>>
>>
>>
>> Better than that, do what I do.
>>
>>
>>
>> 1) Assume that you don't have the full operator precedence table
>>
>> memorized and just parenthesize everything.
>>
>>
>>
>> 2) In cases where the expression is so simple, you couldn't possibly be
>>
>> wrong, see rule #1.
>
> Agreed !
>

Pleased to see that as always plenty of helpful responses here.  In 
return would you please read and action this 
https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing the 
double line spacing above, thanks.

-- 
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]

#65015

Roy Smith writes:

> In article <3dcdc95d-5e30-46d3-b558-afedf9723c7c@googlegroups.com>,
>  Thibault Langlois wrote:
> 
> > You are right. I should have given some context.  I am looking at
> > this from the perspective of the teacher that has to explain
> > idiosyncrasies of the language to inexperienced students.
> >
> > There are two aspects in this example. 

> > 1. the equivalence of True/False with integers 1/0 which have pro
> > and cons.
> > 2. the chaining rules of operators. I agree that it may make sense
> > in some cases like x > y > z but when operators are mixed it leads
> > to counter intuitive cases as the one I pointed out.
> > 
> > The recommendations to student are 1) do not assume True == 1 and
> > do not use operator chaining.
> 
> Better than that, do what I do.
> 
> 1) Assume that you don't have the full operator precedence table
> memorized and just parenthesize everything.
> 
> 2) In cases where the expression is so simple, you couldn't possibly
> be wrong, see rule #1.

There's nothing to parenthesize in x <= y < z = w, unless you mean
something rather weird that is not equivalent anyway (and may not be
compatible with avoiding assumptions like True == 1).

There's not much to remember: the comparison operators are a
semantically coherent class (as far as I can see) and have the same
precedence level somewhere between proper operators (let's call them
that) and and and or and if else[1]. Ok, I'm not quite sure how the
two branches of a conditional expression combine. Rather than find
out, use parentheses, yes:

   (x + 1) if c else x ==  x + (1 if c else 0) == x + bool(c)

I agree about using parentheses when in doubt, but there is some room
here for more education and less doubt. Python gets these right.

[1] Sorry...

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

#65035

On Thursday, January 30, 2014 9:56:19 AM UTC-5, Jussi Piitulainen wrote:

> There's nothing to parenthesize in x <= y < z = w

Hmm....

>>> x <= y < z = w
  File "<stdin>", line 1
SyntaxError: can't assign to comparison

I don't think any number of parentheses will help that :-)

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

#65045

Roy Smith writes:

> On Thursday, January 30, 2014 9:56:19 AM UTC-5, Jussi Piitulainen wrote:
> 
> > There's nothing to parenthesize in x <= y < z = w
> 
> Hmm....
> 
> >>> x <= y < z = w
>   File "<stdin>", line 1
> SyntaxError: can't assign to comparison
> 
> I don't think any number of parentheses will help that :-)

Er, sorry about that. Here:

>>> x <= y < z == w
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined

Much better :)

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

#65047

On Fri, Jan 31, 2014 at 7:14 AM, Jussi Piitulainen
<jpiitula@ling.helsinki.fi> wrote:
>> I don't think any number of parentheses will help that :-)
>
> Er, sorry about that. Here:
>
>>>> x <= y < z == w
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> NameError: name 'x' is not defined
>
> Much better :)

See, you still all think the solution is with parentheses and stuff.
It's not. The solution is with apostrophes - look!

>>> 'x' <= 'y < z == w'
True

Now it works!

ChrisA

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

#65018

On Thu, 30 Jan 2014 09:08:58 -0500, Roy Smith wrote:

> 1) Assume that you don't have the full operator precedence table
> memorized and just parenthesize everything.

Oh really? Do you actually write stuff like this?

b = ((2*a) + 1)
if (b >= (-1)):
    ...


I would hope not.


> 2) In cases where the expression is so simple, you couldn't possibly be
> wrong, see rule #1.


Or, you can avoid superstitious responses *wink*

(1) Learn the operator precedences to the best of your ability. It's
    not hard, most of it works just like the precedences you're used
    to from maths class (remember that?) or in the most intuitively
    useful way.

    E.g. `1 + x == 2` does the useful thing of calculating 1 + x 
    before testing for equality, rather than the stupid thing of
    calculating x == 2 first then adding it to 1.

(2) When in doubt, use parentheses.

(3) When the expression is complex, a few extra parentheses can
    help make it easier to understand. "Seven, plus or minus two"
    is (roughly) the number of distinct items the human short-
    term memory can hold. Grouping terms together can help reduce
    the distinct number of items the reader needs to keep in 
    short-term memory.

    E.g. `x+1 > 0 and y >= 5` is potentially as many as 9 distinct
    items to keep in short-term memory. But bracketing some terms 
    as in `(x+1 > 0) and (y >= 5)` can reduce that down to as few
    as two items.

(4) But too many parens obscure the meaning of the expression too. Aim
    for a good balance, neither too few nor too many. Your judgement 
    of the right number of parens is a skill, which will come with 
    experience.




-- 
Steven

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web