1 > 0 == True -> False

[Roy Smith]

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)

 

[Chris Angelico]

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

 

[Ethan Furman]

Be careful; that's not the same thing.

How so?

 

[Rotwang]

[...]

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

 

[Chris Angelico]

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

 

[Dave Angel]

[...]

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')

 

[Jussi Piitulainen]

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:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined

Much better

 

[Chris Angelico]

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:

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

 

[Chris Angelico]

Er, sorry about that. Here:

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!
True

Now it works!

ChrisA

 

[Ian Kelly]

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

 

[Chris Angelico]

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:
SyntaxError: only named arguments may follow *expression

But I can do this:
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

 

[Ian Kelly]

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:
SyntaxError: only named arguments may follow *expression

But I can do this:

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.

 

[Chris Angelico]

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

 

[Roy Smith]

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

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.

 

[Chris Angelico]

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

 

[Joshua Landau]

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.

 

[Chris Angelico]

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.

Ah, okay. Glad it's not a fundamentally hard concept. I don't know
that I want to dig into actually implementing that, just now, but I've
added myself as nosy on bug 2292 (which is where the patch is being
discussed, and is referenced in the PEP). I don't have a major
use-case for it in Python, though I've used the equivalent Pike
feature all over the place (it's done as @args where args is an array,
and it's equivalent to listing the args - pretty much the same as
*args in Python) - it's handy, even though it's almost never really
crucial.

It's perhaps telling that the only time I can recall running into this
with Python is in making some deliberately bad code

ChrisA

 

[Rotwang]

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.

 

[Rotwang]

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.

 

[Joshua Landau]

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.

http://www.python.org/dev/peps/pep-3113/