Python: if not any trying to understand the difference in handling the output

-1

Checking to see if any of the args were stored true and if not then set them all to true to run all the args. ie can run one arg or if you don't select one it will run them all.

if not any((args.x, args.y, args.z)):

    args.x = args.y = args.z = True '''this works'''



    args.x, args.y, args.z = True '''but this does not work - gives TypeError: cannot unpack non-iterable bool object'''

But it will work if I make a much more ugly if statement like this.

 if args.x is False and args.y is False and args.z is False:

    args.x = args.y = args.z = True '''this works'''

    args.x, args.y, args.z = True '''and this works as well'''

edited Jan 2 at 19:43

Patrick Artner

25.9k62544

asked Jan 2 at 19:04

Fornax

args.x, args.y, args.z = [True]*3

– Patrick Artner
Jan 2 at 19:11

3

I can't reproduce this. The second assignment should always fail because it's attempting to unpack a bool object, which cannot be unpacked.

– Patrick Haugh
Jan 2 at 19:12

1

Add a print statement to the second example inside the if block so you know you're actually entering it. Because the only reason that code should have worked for you is if you never actually made it into the block.

– glibdud
Jan 2 at 19:31

1

Why are you comparing usin is? Use == Use is only for if something is None: .. or if you want to check identity

– Patrick Artner
Jan 2 at 19:41

1

@PatrickArtner Yeah, that could be why he thinks the second block is running when it actually isn't. A more equivalent statement to the first example would be if not args.x and not args.y and not args.z:.

– glibdud
Jan 2 at 19:47

|
show 2 more comments

-1

Checking to see if any of the args were stored true and if not then set them all to true to run all the args. ie can run one arg or if you don't select one it will run them all.

if not any((args.x, args.y, args.z)):

    args.x = args.y = args.z = True '''this works'''



    args.x, args.y, args.z = True '''but this does not work - gives TypeError: cannot unpack non-iterable bool object'''

But it will work if I make a much more ugly if statement like this.

 if args.x is False and args.y is False and args.z is False:

    args.x = args.y = args.z = True '''this works'''

    args.x, args.y, args.z = True '''and this works as well'''

edited Jan 2 at 19:43

Patrick Artner

25.9k62544

asked Jan 2 at 19:04

Fornax

args.x, args.y, args.z = [True]*3

– Patrick Artner
Jan 2 at 19:11

3

I can't reproduce this. The second assignment should always fail because it's attempting to unpack a bool object, which cannot be unpacked.

– Patrick Haugh
Jan 2 at 19:12

1

Add a print statement to the second example inside the if block so you know you're actually entering it. Because the only reason that code should have worked for you is if you never actually made it into the block.

– glibdud
Jan 2 at 19:31

1

Why are you comparing usin is? Use == Use is only for if something is None: .. or if you want to check identity

– Patrick Artner
Jan 2 at 19:41

1

@PatrickArtner Yeah, that could be why he thinks the second block is running when it actually isn't. A more equivalent statement to the first example would be if not args.x and not args.y and not args.z:.

– glibdud
Jan 2 at 19:47

|
show 2 more comments

-1

Checking to see if any of the args were stored true and if not then set them all to true to run all the args. ie can run one arg or if you don't select one it will run them all.

if not any((args.x, args.y, args.z)):

    args.x = args.y = args.z = True '''this works'''



    args.x, args.y, args.z = True '''but this does not work - gives TypeError: cannot unpack non-iterable bool object'''

But it will work if I make a much more ugly if statement like this.

 if args.x is False and args.y is False and args.z is False:

    args.x = args.y = args.z = True '''this works'''

    args.x, args.y, args.z = True '''and this works as well'''

edited Jan 2 at 19:43

Patrick Artner

25.9k62544

asked Jan 2 at 19:04

Fornax

Checking to see if any of the args were stored true and if not then set them all to true to run all the args. ie can run one arg or if you don't select one it will run them all.

if not any((args.x, args.y, args.z)):

    args.x = args.y = args.z = True '''this works'''



    args.x, args.y, args.z = True '''but this does not work - gives TypeError: cannot unpack non-iterable bool object'''

But it will work if I make a much more ugly if statement like this.

 if args.x is False and args.y is False and args.z is False:

    args.x = args.y = args.z = True '''this works'''

    args.x, args.y, args.z = True '''and this works as well'''

python python-3.x

edited Jan 2 at 19:43

Patrick Artner

25.9k62544

asked Jan 2 at 19:04

Fornax

edited Jan 2 at 19:43

Patrick Artner

25.9k62544

asked Jan 2 at 19:04

Fornax

edited Jan 2 at 19:43

Patrick Artner

25.9k62544

edited Jan 2 at 19:43

Patrick Artner

25.9k62544

edited Jan 2 at 19:43

Patrick Artner

25.9k62544

asked Jan 2 at 19:04

Fornax

asked Jan 2 at 19:04

Fornax

asked Jan 2 at 19:04

Fornax

args.x, args.y, args.z = [True]*3

– Patrick Artner
Jan 2 at 19:11

3

I can't reproduce this. The second assignment should always fail because it's attempting to unpack a bool object, which cannot be unpacked.

– Patrick Haugh
Jan 2 at 19:12

1

Add a print statement to the second example inside the if block so you know you're actually entering it. Because the only reason that code should have worked for you is if you never actually made it into the block.

– glibdud
Jan 2 at 19:31

1

Why are you comparing usin is? Use == Use is only for if something is None: .. or if you want to check identity

– Patrick Artner
Jan 2 at 19:41

1

@PatrickArtner Yeah, that could be why he thinks the second block is running when it actually isn't. A more equivalent statement to the first example would be if not args.x and not args.y and not args.z:.

– glibdud
Jan 2 at 19:47

|
show 2 more comments

args.x, args.y, args.z = [True]*3

– Patrick Artner
Jan 2 at 19:11

3

I can't reproduce this. The second assignment should always fail because it's attempting to unpack a bool object, which cannot be unpacked.

– Patrick Haugh
Jan 2 at 19:12

1

Add a print statement to the second example inside the if block so you know you're actually entering it. Because the only reason that code should have worked for you is if you never actually made it into the block.

– glibdud
Jan 2 at 19:31

1

Why are you comparing usin is? Use == Use is only for if something is None: .. or if you want to check identity

– Patrick Artner
Jan 2 at 19:41

1

@PatrickArtner Yeah, that could be why he thinks the second block is running when it actually isn't. A more equivalent statement to the first example would be if not args.x and not args.y and not args.z:.

– glibdud
Jan 2 at 19:47

args.x, args.y, args.z = [True]*3

– Patrick Artner
Jan 2 at 19:11

I can't reproduce this. The second assignment should always fail because it's attempting to unpack a bool object, which cannot be unpacked.

– Patrick Haugh
Jan 2 at 19:12

Add a print statement to the second example inside the if block so you know you're actually entering it. Because the only reason that code should have worked for you is if you never actually made it into the block.

– glibdud
Jan 2 at 19:31

Why are you comparing usin is? Use == Use is only for if something is None: .. or if you want to check identity

– Patrick Artner
Jan 2 at 19:41

@PatrickArtner Yeah, that could be why he thinks the second block is running when it actually isn't. A more equivalent statement to the first example would be if not args.x and not args.y and not args.z:.

– glibdud
Jan 2 at 19:47

|
show 2 more comments

1 Answer
1

active

oldest

votes

If you have 3 variables on the left side of an assignment, you need to have 3 on the right side as well. This:

args.x, args.y, args.z = True

has 3 values on the left and only 1 on the right. Try doing this:

args.x, args.y, args.z = True, True, True

or this:

args.x, args.y, args.z = [True for i in range(3)]

This statement:

args.x = args.y = args.z = True

works the same as this:

args.x = True

args.y = True

args.z = True

which is legal python code.

edited Jan 2 at 20:02

ShadowRanger

63.3k66099

answered Jan 2 at 19:51

Pikachu the Purple Wizard

2,03761329

1

You're mostly correct, but args.x = args.y = args.z = True does not work the way you describe. If it did, and x or y were weird property things that didn't necessarily return what they were set to, you'd have unpredictable behavior. The ordering is also wrong; Python assigns from left to right, even here. The actual behavior is more like __unnamed = True, args.x = __unnamed, args.y = __unnamed, args.z = __unnamed (__unnamed is actually a value shoved on the frame's stack, duplicated to fill all the assignment targets). You're probably thinking of C assignment semantics.

– ShadowRanger
Jan 2 at 19:57

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54011818%2fpython-if-not-any-trying-to-understand-the-difference-in-handling-the-output%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

If you have 3 variables on the left side of an assignment, you need to have 3 on the right side as well. This:

args.x, args.y, args.z = True

has 3 values on the left and only 1 on the right. Try doing this:

args.x, args.y, args.z = True, True, True

or this:

args.x, args.y, args.z = [True for i in range(3)]

This statement:

args.x = args.y = args.z = True

works the same as this:

args.x = True

args.y = True

args.z = True

which is legal python code.

edited Jan 2 at 20:02

ShadowRanger

63.3k66099

answered Jan 2 at 19:51

Pikachu the Purple Wizard

2,03761329

1

You're mostly correct, but args.x = args.y = args.z = True does not work the way you describe. If it did, and x or y were weird property things that didn't necessarily return what they were set to, you'd have unpredictable behavior. The ordering is also wrong; Python assigns from left to right, even here. The actual behavior is more like __unnamed = True, args.x = __unnamed, args.y = __unnamed, args.z = __unnamed (__unnamed is actually a value shoved on the frame's stack, duplicated to fill all the assignment targets). You're probably thinking of C assignment semantics.

– ShadowRanger
Jan 2 at 19:57

add a comment |

If you have 3 variables on the left side of an assignment, you need to have 3 on the right side as well. This:

args.x, args.y, args.z = True

has 3 values on the left and only 1 on the right. Try doing this:

args.x, args.y, args.z = True, True, True

or this:

args.x, args.y, args.z = [True for i in range(3)]

This statement:

args.x = args.y = args.z = True

works the same as this:

args.x = True

args.y = True

args.z = True

which is legal python code.

edited Jan 2 at 20:02

ShadowRanger

63.3k66099

answered Jan 2 at 19:51

Pikachu the Purple Wizard

2,03761329

1

You're mostly correct, but args.x = args.y = args.z = True does not work the way you describe. If it did, and x or y were weird property things that didn't necessarily return what they were set to, you'd have unpredictable behavior. The ordering is also wrong; Python assigns from left to right, even here. The actual behavior is more like __unnamed = True, args.x = __unnamed, args.y = __unnamed, args.z = __unnamed (__unnamed is actually a value shoved on the frame's stack, duplicated to fill all the assignment targets). You're probably thinking of C assignment semantics.

– ShadowRanger
Jan 2 at 19:57

add a comment |

If you have 3 variables on the left side of an assignment, you need to have 3 on the right side as well. This:

args.x, args.y, args.z = True

has 3 values on the left and only 1 on the right. Try doing this:

args.x, args.y, args.z = True, True, True

or this:

args.x, args.y, args.z = [True for i in range(3)]

This statement:

args.x = args.y = args.z = True

works the same as this:

args.x = True

args.y = True

args.z = True

which is legal python code.

edited Jan 2 at 20:02

ShadowRanger

63.3k66099

answered Jan 2 at 19:51

Pikachu the Purple Wizard

2,03761329

If you have 3 variables on the left side of an assignment, you need to have 3 on the right side as well. This:

args.x, args.y, args.z = True

has 3 values on the left and only 1 on the right. Try doing this:

args.x, args.y, args.z = True, True, True

or this:

args.x, args.y, args.z = [True for i in range(3)]

This statement:

args.x = args.y = args.z = True

works the same as this:

args.x = True

args.y = True

args.z = True

which is legal python code.

edited Jan 2 at 20:02

ShadowRanger

63.3k66099

answered Jan 2 at 19:51

Pikachu the Purple Wizard

2,03761329

edited Jan 2 at 20:02

ShadowRanger

63.3k66099

edited Jan 2 at 20:02

ShadowRanger

63.3k66099

edited Jan 2 at 20:02

ShadowRanger

63.3k66099

answered Jan 2 at 19:51

Pikachu the Purple Wizard

2,03761329

answered Jan 2 at 19:51

Pikachu the Purple Wizard

2,03761329

answered Jan 2 at 19:51

Pikachu the Purple Wizard

2,03761329

1

You're mostly correct, but args.x = args.y = args.z = True does not work the way you describe. If it did, and x or y were weird property things that didn't necessarily return what they were set to, you'd have unpredictable behavior. The ordering is also wrong; Python assigns from left to right, even here. The actual behavior is more like __unnamed = True, args.x = __unnamed, args.y = __unnamed, args.z = __unnamed (__unnamed is actually a value shoved on the frame's stack, duplicated to fill all the assignment targets). You're probably thinking of C assignment semantics.

– ShadowRanger
Jan 2 at 19:57

add a comment |

1

You're mostly correct, but args.x = args.y = args.z = True does not work the way you describe. If it did, and x or y were weird property things that didn't necessarily return what they were set to, you'd have unpredictable behavior. The ordering is also wrong; Python assigns from left to right, even here. The actual behavior is more like __unnamed = True, args.x = __unnamed, args.y = __unnamed, args.z = __unnamed (__unnamed is actually a value shoved on the frame's stack, duplicated to fill all the assignment targets). You're probably thinking of C assignment semantics.

– ShadowRanger
Jan 2 at 19:57

You're mostly correct, but args.x = args.y = args.z = True does not work the way you describe. If it did, and x or y were weird property things that didn't necessarily return what they were set to, you'd have unpredictable behavior. The ordering is also wrong; Python assigns from left to right, even here. The actual behavior is more like __unnamed = True, args.x = __unnamed, args.y = __unnamed, args.z = __unnamed (__unnamed is actually a value shoved on the frame's stack, duplicated to fill all the assignment targets). You're probably thinking of C assignment semantics.

– ShadowRanger
Jan 2 at 19:57

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu