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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#65024

On Thursday, January 30, 2014 8:39:03 PM UTC+5:30, Steven D'Aprano wrote:
> 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.



(5) use APL -- all ordinary operators group right to left and at the same
precedence level

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

#65037

On Thursday, January 30, 2014 10:09:03 AM UTC-5, Steven D'Aprano wrote:
> 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)

Well, OK, I exaggerated a bit.  Multiplication binds stronger than addition in any language I've ever used, so I assume I know that one.  But not much beyond that.

> if (b >= (-1)):

No, I wouldn't use either set of parens their either.  But, if I have any doubt at all, I rather than look it up, I just put parens.  And my threshold for doubt is pretty low.

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

#65080

On Friday, January 31, 2014 12:23:42 AM UTC+5:30, Roy Smith wrote:
> On Thursday, January 30, 2014 10:09:03 AM UTC-5, Steven D'Aprano wrote:
> > 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)

> Well, OK, I exaggerated a bit.  Multiplication binds stronger than addition 
> in any language I've ever used, so I assume I know that one.  But not much 
> beyond that.

Not in APL. And horners rule is one touted advantage of that

  ax³ + bx² + cx + d
= d + xc + x²b + x³a
= d + x(c + xb + x²a)
= d + x(c + x(b + xa)

Now APL by precedence rules
- add and multiply are same precedence
- multiply denoted with ×
- all grouping right to left

We have last equal to
 d + x×c + x×b + x×a 


> > if (b >= (-1)):


> No, I wouldn't use either set of parens their either.  But, if I have any doubt at all, I rather than look it up, I just put parens.  And my threshold for doubt is pretty low.


APL:  b ≥ ¯1
ie ¯ is part of the constant and - is not ad-hoc overloaded

I wont talk of the if because that will spoil the fun
And this is a unicode experiment!

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

#65038

On Thursday, January 30, 2014 10:09:03 AM UTC-5, Steven D'Aprano wrote:

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

Yes, that's probably how I would write that, although, this is even simpler:

(x > -1) and (y >= 5)

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

#65039

On Fri, Jan 31, 2014 at 5:56 AM, Roy Smith <roy@panix.com> wrote:
> On Thursday, January 30, 2014 10:09:03 AM UTC-5, Steven D'Aprano wrote:
>
>>     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.
>
> Yes, that's probably how I would write that, although, this is even simpler:
>
> (x > -1) and (y >= 5)

Be careful; that's not the same thing.

ChrisA

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

#65053

On Thursday, January 30, 2014 10:09:03 AM UTC-5, Steven D'Aprano wrote:
> `(x+1 > 0) and (y >= 5)`

Me:
> this is even simpler:
> (x > -1) and (y >= 5)

On Thursday, January 30, 2014 2:03:42 PM UTC-5, Chris Angelico wrote:
> Be careful; that's not the same thing.

In what way?  I'm assuming x is some numeric type.  And further assuming it's not some humungous floating point value, so we run into precision issues.

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

#65055

On Fri, Jan 31, 2014 at 9:09 AM, Roy Smith <roy@panix.com> wrote:
> On Thursday, January 30, 2014 10:09:03 AM UTC-5, Steven D'Aprano wrote:
>> `(x+1 > 0) and (y >= 5)`
>
> Me:
>> this is even simpler:
>> (x > -1) and (y >= 5)
>
> On Thursday, January 30, 2014 2:03:42 PM UTC-5, Chris Angelico wrote:
>> Be careful; that's not the same thing.
>
> In what way?  I'm assuming x is some numeric type.  And further assuming it's not some humungous floating point value, so we run into precision issues.

Now you're changing the problem domain :) Like I said, if it's an
integer, you definitely will get the same result from each of the
above; but that doesn't mean the expressions are equivalent. They just
might happen to produce the same result for values within some
particular domain. (I wouldn't even be 100% confident that it's valid
for any numeric type, though I can't think of any float values that it
would break on, and complex and int are unorderable anyway.)

ChrisA

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

#65042

On 01/30/2014 11:03 AM, Chris Angelico wrote:
> On Fri, Jan 31, 2014 at 5:56 AM, Roy Smith wrote:
>>
>> Yes, that's probably how I would write that, although, this is even simpler:
>>
>> (x > -1) and (y >= 5)
>
> Be careful; that's not the same thing.

How so?

--
~Ethan~

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

#65043

 Fri, Jan 31, 2014 at 6:22 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
> On 01/30/2014 11:03 AM, Chris Angelico wrote:
>
>> On Fri, Jan 31, 2014 at 5:56 AM, Roy Smith wrote:
>>>
>>>
>>> Yes, that's probably how I would write that, although, this is even
>>> simpler:
>>>
>>> (x > -1) and (y >= 5)
>>
>>
>> Be careful; that's not the same thing.
>
>
> How so?
>

Well, if x is an integer, then they're the same. If it's floating
point, I think they're the same, but don't quote me on that. But for
arbitrary types, there's no way of knowing what x+1 will result in.

ChrisA

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

#65040

On 30/01/2014 12:49, Dave Angel wrote:
> [...]
>
> 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.

Really? I take advantage of it quite a lot. For example, I do things 
like this:

'You have scored %i point%s' % (score, 's'*(score != 1))

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

#65044

 Rotwang <sg552@hotmail.co.uk> Wrote in message:
> On 30/01/2014 12:49, Dave Angel wrote:
>> [...]
>>
>> 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.
> 
> Really? I take advantage of it quite a lot. For example, I do things 
> like this:
> 
> 'You have scored %i point%s' % (score, 's'*(score != 1))
> 

I also did that kind of thing when computer resources
were more
 precious the program readability.  Like in 73 when my satellite
 navigation system had to fit in 2k code and 1.5k
 data.

Here I'd probably do something like

'You have scored {} {}' .format (score, 'point' if score==1 else
 'points')

-- 
DaveA

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

#65046

On Fri, Jan 31, 2014 at 7:08 AM, Dave Angel <davea@davea.name> wrote:
>> 'You have scored %i point%s' % (score, 's'*(score != 1))
>>
>
> Here I'd probably do something like
>
> 'You have scored {} {}' .format (score, 'point' if score==1 else
>  'points')

Bah, what's the fun in that?

'You have scored %i point%.*s' % (score, score!=1, 's')

BTW, the layout of the original bugs me slightly:

>> 'You have scored %i point%s' % (score, 's'*(score != 1))

I don't like having spaces around != and none around *. I'd either
squash the != up or space out the *:

'You have scored %i point%s' % (score, 's'*(score!=1))
'You have scored %i point%s' % (score, 's' * (score != 1))

Operators should always have at least as much space around them as
more tightly-binding operators, IMO. In this instance, it'd be
reasonable to squash the != and space the *, or to squash both, or to
space both, but not the "backward" spacing of the original :)

But that's just my opinion.

ChrisA

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

#65048

On Thu, Jan 30, 2014 at 1:08 PM, Dave Angel <davea@davea.name> wrote:
>  Rotwang <sg552@hotmail.co.uk> Wrote in message:
>> Really? I take advantage of it quite a lot. For example, I do things
>> like this:
>>
>> 'You have scored %i point%s' % (score, 's'*(score != 1))
>>
>
> I also did that kind of thing when computer resources
> were more
>  precious the program readability.  Like in 73 when my satellite
>  navigation system had to fit in 2k code and 1.5k
>  data.
>
> Here I'd probably do something like
>
> 'You have scored {} {}' .format (score, 'point' if score==1 else
>  'points')

Of course if you're at all concerned about i18n then the proper way to
do it would be:

ngettext("You have scored %d point", "You have scored %d points", score) % score

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

#65049

On Fri, Jan 31, 2014 at 7:28 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> Of course if you're at all concerned about i18n then the proper way to
> do it would be:
>
> ngettext("You have scored %d point", "You have scored %d points", score) % score

Ugh, so much duplication! We can totally do better than that.

ngettext(*(lambda x,s: (x,x+'s',s))("You have scored %d point",score))

Much better!


Incidentally, in creating the above abomination, I found that I can't do this:

>>> print(*(lambda x: (x,x+'s'))("You have scored %d point"),score)
SyntaxError: only named arguments may follow *expression

But I can do this:

>>> print(score,*(lambda x: (x,x+'s'))("You have scored %d point"))
1 You have scored %d point You have scored %d points

Why is tuple unpacking limited to the last argument? Is it just for
the parallel with the function definition, where anything following it
is keyword-only?

ChrisA

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

#65050

[Multipart message — attachments visible in raw view] — view raw

On Jan 30, 2014 1:40 PM, "Chris Angelico" <rosuav@gmail.com> wrote:
>
> On Fri, Jan 31, 2014 at 7:28 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> > Of course if you're at all concerned about i18n then the proper way to
> > do it would be:
> >
> > ngettext("You have scored %d point", "You have scored %d points",
score) % score
>
> Ugh, so much duplication! We can totally do better than that.
>
> ngettext(*(lambda x,s: (x,x+'s',s))("You have scored %d point",score))
>
> Much better!
>
>
> Incidentally, in creating the above abomination, I found that I can't do
this:
>
> >>> print(*(lambda x: (x,x+'s'))("You have scored %d point"),score)
> SyntaxError: only named arguments may follow *expression
>
> But I can do this:
>
> >>> print(score,*(lambda x: (x,x+'s'))("You have scored %d point"))
> 1 You have scored %d point You have scored %d points
>
> Why is tuple unpacking limited to the last argument? Is it just for
> the parallel with the function definition, where anything following it
> is keyword-only?

Lack of a convincing use case, and the position of the following arguments
would then be dependent upon the length of the tuple, which in many cases
could result in subtle bugs.

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

#65051

On Fri, Jan 31, 2014 at 8:17 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> Why is tuple unpacking limited to the last argument? Is it just for
>> the parallel with the function definition, where anything following it
>> is keyword-only?
>
> Lack of a convincing use case, and the position of the following arguments
> would then be dependent upon the length of the tuple, which in many cases
> could result in subtle bugs.

Okay. Just seemed an odd restriction; I can unpack an iterable into a
function's args (great!), I can have other args before that tuple
(handy!), but I can't have any after.

ChrisA

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

#65068

On 30 January 2014 20:38, Chris Angelico <rosuav@gmail.com> wrote:
>
> Why is tuple unpacking limited to the last argument? Is it just for
> the parallel with the function definition, where anything following it
> is keyword-only?

You're not the first person to ask that:
http://www.python.org/dev/peps/pep-0448/

If you're able and willing to implement it, I believe the support is
there. The primary reason I know of for its non-inclusion was that it
was first proposed (with code) during a feature freeze.

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

#65070

On 30/01/2014 23:36, Joshua Landau wrote:
> On 30 January 2014 20:38, Chris Angelico <rosuav@gmail.com> wrote:
>>
>> Why is tuple unpacking limited to the last argument? Is it just for
>> the parallel with the function definition, where anything following it
>> is keyword-only?
>
> You're not the first person to ask that:
> http://www.python.org/dev/peps/pep-0448/

On a vaguely-related note, does anyone know why iterable unpacking in 
calls was removed in Python 3? I mean things like

def f(x, (y, z)):
     return (x, y), z

I don't have a use case in mind, I was just wondering.

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

#65071 — Removal of iterable unpacking in function calls (was: 1 > 0 == True -> False)

Rotwang <sg552@hotmail.co.uk> writes:

> On a vaguely-related note, does anyone know why iterable unpacking in
> calls was removed in Python 3?

This is explained in the PEP which described its removal
<URL:http://www.python.org/dev/peps/pep-3113/>, especially
<URL:http://www.python.org/dev/peps/pep-3113/#why-they-should-go>.

-- 
 \         “My, your, his, hers, ours, theirs, its. I'm, you're, he's, |
  `\   she's, we're, they're, it's.” —anonymous, alt.sysadmin.recovery |
_o__)                                                                  |
Ben Finney

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

#65073 — Re: Removal of iterable unpacking in function calls

On 31/01/2014 00:21, Ben Finney wrote:
> Rotwang <sg552@hotmail.co.uk> writes:
>
>> On a vaguely-related note, does anyone know why iterable unpacking in
>> calls was removed in Python 3?
>
> This is explained in the PEP which described its removal
> <URL:http://www.python.org/dev/peps/pep-3113/>, especially
> <URL:http://www.python.org/dev/peps/pep-3113/#why-they-should-go>.

Ah, I had not seen that. Thanks.

[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