How do you check to see if an input is equal to a certain integer or integers?

Question

I know how to check if an input is an integer but not a specific integer. For example for my code I want to check if the input is equal to 1, 2 or 3 and then ask the user to input again if the input isn't equal to 1, 2 or 3.

Help is greatly appreciated :)

score 3 · Accepted Answer · answered May 26 '15 at 08:07

3

That would be:

if var in (1, 2, 3):

Or for any integer:

if isinstance(var, int):

answered May 26 '15 at 08:07

Lennart Regebro

167,292
41
224
251

The complement of this being `if var not in (1, 2, 3):` – Phylogenesis May 26 '15 at 08:08
I've done this but it doesn't work, it just goes straight to the else line and prints('Is not equal to 1, 2 or 3) var=input() if var in (1,2,3): print('Is equal to 1, 2 or 3') else: print('Is not equal to 1, 2 or 3') – A lvl 86 Lemon May 26 '15 at 08:21
@jonrsharpe maybe add a line where var is cast to an int for the condition to perform as expected. Or "if isinstance(var, int) and var in (1, 2, 3):" – ypx May 26 '15 at 08:24
Ok yeah I was being stupid it works now. Thanks! I just put, if var in(str(1), str(2) and str(3)): instead – A lvl 86 Lemon May 26 '15 at 08:24
Well, `if var in ('1', '2', '3'):` is better then. But note that this is not integers, but strings, so that's not what you asked for. ;-) – Lennart Regebro May 26 '15 at 08:36

score -1 · Answer 2 · answered May 26 '15 at 08:36

-1

def restricted_input(prompt, values):
    assert values
    while True:
        typed = input(prompt)
        for acceptable in values:
            if typed == str(acceptable):
                return acceptable
        else:
            print("Acceptable values are from ", values)

Then in your program...

choice = restricted_input("Enter a number: ", {1, 2, 3})

answered May 26 '15 at 08:36

Veky

2,646
1
21
30

Why do you `assert values`? – TigerhawkT3 May 26 '15 at 08:39
Because when values is empty, the function doesn't make sense. – Veky May 26 '15 at 09:01
1

If you use assertions to do that, your program will crash if there are no values. Additionally, assertions can be turned off, eliminating the check entirely. Use `if not values: return` instead. – TigerhawkT3 May 26 '15 at 09:13
Imagine someone wants a function to divide two numbers. Do you code `def divide(a, b): if not b: return`?? Of course not. `None` is not always acceptable return value [User might rely on the postcondition `restricted_input(whatever, values) in values`]. Sometimes you need to raise an exception when you're required to do something that doesn't make sense. And that doesn't mean the program will crash - exception can be handled, and even if it wasn't, "crash" is a strange word for getting a precise traceback. – Veky May 26 '15 at 17:26
If you really want to raise an exception, use `raise`. Don't use `assert` as part of your algorithm. – TigerhawkT3 May 26 '15 at 17:33
I must say I don't understand you. Would it be ok if I had a comment `# This function assumes nonempty values` at the beginning? Because in my head, that's exactly what `assert` does (only understandable to Python). Why are you so opposed to it?? – Veky May 26 '15 at 17:36
Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/78828/discussion-between-veky-and-tigerhawkt3). – Veky May 26 '15 at 17:43
See [here](http://stackoverflow.com/questions/5142418/) and [here](https://docs.python.org/2/reference/simple_stmts.html#assert) for more on `assert`. – TigerhawkT3 May 26 '15 at 18:56
Fascinating. You please see https://wiki.python.org/moin/UsingAssertionsEffectively . :-) "they're good for catching false assumptions that were made while writing the code, or abuse of an interface by another programmer. In addition, they can act as in-line documentation to some extent, by making the programmer's assumptions obvious." Sounds perfectly aligned with this. Also: "Places to consider putting assertions: checking parameter types, classes, or values". BTW if this were coded in statically typed language with flexible types, `values:NonEmptyList` would be completely ok with you? – Veky May 26 '15 at 19:04
Yes, they catch false assumptions, etc. and so forth... _during testing_, not as part of your algorithm. As I said earlier, assertions can also be turned off when you're done testing - this is obviously problematic if your algorithm relies on an assertion. – TigerhawkT3 May 26 '15 at 19:17
It seems you have a fixed idea that noone can convince you out of. Surely you don't think that "They can act as in-line documentation to some extent" _during testing_?? Let me just try this, and then I'll give up: "Assertions are not a substitute for unit tests or system tests, but rather a complement. Because assertions are a clean way to examine the internal state of an object or function, they provide 'for free' a clear-box assistance to a black-box test that examines the external behaviour." It's not a problem at all that they can be turned off - as I said, it's a Python-readable comment. – Veky May 26 '15 at 20:27
Exactly - they are there to assist testing, not to serve as part of your algorithm. If you call a script with `py -O myscript.py`, it will skip over all `assert` statements. You can try it yourself if you don't believe me. This is why you should use `raise` if you intend your actual code to raise an exception in some situation. – TigerhawkT3 May 26 '15 at 20:48
As I said, trying to explain something to you it's probably lost cause. If you want to say something more, please move it to chat. – Veky May 26 '15 at 21:02
Just one more point, and then I'll shut up. http://import-that.dreamwidth.org/676.html (Of course, you have many more points made in the chat.) – Veky May 27 '15 at 07:44

How do you check to see if an input is equal to a certain integer or integers?

2 Answers2