Straight off the bat, why learn 2.7 instead of 3?

Also, just check if the input is in an array. Use something like:

valid = {"Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"}
while is_valid == 0:
check = raw_input("> ")
for x in valid:
if x == check:
is_valid = 1

Mind you, that would require your user to type one of those exact values. ie; "Janurary" or "feb" wouldn't work.

You could just have them type in the month number, which would be a lot easier to do:
check = raw_input("> ")
while is_valid == 0:
if check > 0:
if check < 12:
is_valid = 1

If you want a challenge; try to use some sort of regex to check the month name and use it with the array.

>>158
Fucking kusaba removing my painstakingly-placed spaces to keep the indentation correct. Aren't there [code] tags or something?

>>159
We had them back in /pr/.

testing the code tags

SAGE has been used.

>>158
Thanks for the help, I don't really know much about arrays, so it never occurred to me to use them. I'll give that a shot though.

>>158
Just tried the code out. I made some modifications and got it to work flawlessly. I appreciate the help.

The code, in case someone wants to see it:

is_valid = 0 valid = {"Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"} while is_valid == 0: check = raw_input("> ") for x in valid: if x == check: is_valid = 1 print "Valid Month" if is_valid == 0: print "Invalid Month"

Wow, not even [code] tags keep the goddamn indentation.

>>162
Im not sure why you are using ints instead of booleans, but even so, a more pythonic way of doing it would be something like this:

valid = ("Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec")
if raw_input("> ") in valid:
print "Valid Month"
else:
print "Invalid Month"

>>166
And an even more correct way would be to use a list instead of a giant tuple (tuples are in (), lists are in [], and this makes a difference for two reasons). The exception being if you want the order of the months to mean something (and they IRL, so if this were to be expanded upon later, that would make sense as a design choice).

Anyway, OP, it looks to me like you'd benefit greatly from just working through the Python tutorial. It covers predefined data types pretty well, though just why some of Python's data types are so slick won't really sink in until you work on large projects in a few other languages first.

>>167
Interesting, I figured a tuple should be used because the data it contains is immutable. Just out of curiosity, what are the two reasons for using a list instead of a tuple?

>>177
Hi there. Good question.

The idea that "I should use this because the data type is immutable" is wrong for a few reasons. For one thing, everything is mutable, either because its got an interface that makes that easy or because you can backhack the data type and change stuff on your own. The fact we're programming at all is evidence of this -- so don't let a shallow book or teacher put that idea into your head. Besides, if you're programming something I'd assume you know what you're up to, and so protecting your own data from you is sort of a weird language decision.

With that out of the way...

The reason tuples are immutable is the same reason they are not the same as lists and don't share the same methods as objects in Python: symantic meaning being tied to the order of the set members.

The famous example is storing a tuple of a/s/l location. You know the first one means "Age" and not "Location" or "Sex". That means you can't just randomly push or pop stuff inside this because its not a list, its a tuple and adding or removing a set member would confuse the meaning of the set entirely.
(age, sex, location) is a lot more sensible than [age, sex, location].

But an unordered list of people, on the other hand, that's different. I can push and pop all I want and it doesn't change the fact that the next thing in line is the same *type* of data. So in this case a tuple containing a list of people is silly, not just because its "immutable" but because the locations implicity have a meaning of their own -- which is the reason why its an "immutable" data structure in the first place.
[(alice.age, alice.sex, alice.location), (bob.age, bob.sex, bob.location)] is the way to go here.

In this case OP was only trying to establish validity through comparison, and semantics were completely out the window. Lists are more correct for this (and more efficient). I had originally said if the program were to be expanded to leave it as a tuple because position might matter later -- and that was me implying that positions in tuples have semantic meanings of their own.

Really, in the case of months and text input, assuming a 3-letter, case specific abbreviation from a user is a long shot at best, so you'd probably want a layered data type to accept a variety of (wrong) input. A tuple to hold positions, each position containing a list of acceptable input would work and not be hard:
(['1', 'Jan', 'January'], ['2', 'Feb', 'Feburary']...)

And now in this case the positions mean something in the tuple, and we can still ask the system questions based on at least a variety of input within unordered sets living within that tuple. We get even more correct if we incorporate regular expressions which are fed comparisons based on the contents of the tuple of lists (in which case we can totally remove any partials like "Jan"). And problems like this are why list comprehensions were brought over from Haskell...

Blah blah blah...
1- Tuples imply positional semantics and therefore are immutable (not "are immutable and therefore imply semantics" a subtle difference in thinking, but important when designing things).
2- A point I didn't really address because its a huge topic is efficiency in this use case (which can shift with which Python implementation you use...).

>>178
Something worth pointing out to a fledgling hacker that is implicit in the tuple type is that tuples are ad hoc data types of their own.

Let that sink in. A tuple of (age, sex, location) is NOT usable in the same parts of your program that a tuple of (location.address, location.shippable_bool, location.country) is. They are weak data types of their own, flexible in nature and sort of the modernish version of a struct in C.

Elsewhere on this board I mentioned that the real language of a program system is *not* "Python" or "C" or whatever -- that is the syntacic and execution environment, not the real language of the project itself. The language of a project is what you are defining as you write it. This thing about the true nature of tuples is one example of how that manifests.

Think on that until your Zen bell dings, because this is critical to understanding good programming.

...and from now on you will likely get annoyed at how much abuse compound tuples get that should be lists of tuples or tuples of lists simply because they guy typing didn't know the difference and two (('s is easier than ([ or [(...

Also, if you need to create an unordered type with arbitrary semantics, in Python use a dictionary. That's what its for. It trades the freedom of unordered set members and lots of data manipulation methods for the encumberance of keys.

I forgot to mention that about dictionaries. Anyway, this is the design decision behind having three distinct structures in Python for defining sets.

>>178
I decided to look around and do some tests.
The creation of tuples is much faster than lists, but accessing elements in a list is faster than a tuple.
From the tests I did, 12 elements in a tuple really isnt that many, so accessing really isnt that much of a problem.

The following tests were done using `python -m timeit -n 1000000` on Ubuntu 11.04 with Python 2.6.6
Example test: python -m timeit -n 1000000 "valid = ('Jan','Feb','Mar','Apr','May','Jun','Jul','Aug','Sep','Oct','Nov','Dec')" "if 'Jan' in valid: pass"

Tuple -> Jan
1000000 loops, best of 3: 0.105 usec per loop
List -> Jan
1000000 loops, best of 3: 0.388 usec per loop

Tuple -> Feb
1000000 loops, best of 3: 0.133 usec per loop
List -> Feb
1000000 loops, best of 3: 0.414 usec per loop

Tuple -> Mar
1000000 loops, best of 3: 0.165 usec per loop
List -> Mar
1000000 loops, best of 3: 0.44 usec per loop

Tuple -> Apr
1000000 loops, best of 3: 0.175 usec per loop
List -> Apr
1000000 loops, best of 3: 0.455 usec per loop

Tuple -> May
1000000 loops, best of 3: 0.226 usec per loop
List -> May
1000000 loops, best of 3: 0.51 usec per loop

Tuple -> Jun
1000000 loops, best of 3: 0.25 usec per loop
List -> Jun
1000000 loops, best of 3: 0.537 usec per loop

Tuple -> Jul
1000000 loops, best of 3: 0.306 usec per loop
List -> Jul
1000000 loops, best of 3: 0.587 usec per loop

Tuple -> Aug
1000000 loops, best of 3: 0.29 usec per loop
List -> Aug
1000000 loops, best of 3: 0.58 usec per loop

Tuple -> Sep
1000000 loops, best of 3: 0.288 usec per loop
List -> Sep
1000000 loops, best of 3: 0.575 usec per loop

Tuple -> Oct
1000000 loops, best of 3: 0.323 usec per loop
List -> Oct
1000000 loops, best of 3: 0.605 usec per loop

Tuple -> Nov
1000000 loops, best of 3: 0.33 usec per loop
List -> Nov
1000000 loops, best of 3: 0.626 usec per loop

Tuple -> Dec
1000000 loops, best of 3: 0.372 usec per loop
List -> Dec
1000000 loops, best of 3: 0.653 usec per loop

Tuple -> Bad
1000000 loops, best of 3: 0.373 usec per loop
List -> Bad
1000000 loops, best of 3: 0.662 usec per loop

As you can see, when searching for the first element of a list a tuple is about 3 times faster, but once every element has to be accessed, a tuple is only 2 times faster.

That being said, your a/s/l example makes sense to use a tuple over a list, as the position matters, and the list of people makes sense as you are not aware of the number of people and the order doesn't matter, but unless you are writing a small script, to me it would make more sense to use neither and instead make a small asl/person class.

To me, when I see something like (['1', 'Jan', 'January'], ['2', 'Feb', 'Feburary']...), it makes me think that the number of months is set, but the contents of a month may change during runtime, and for OP's example where he has a set of valid inputs to be used to validate user input, I am still not seeing why you would use a list over a tuple, or maybe I just missed your point completely.

More fun, and really telling on performance in a very common use case, is to do some timing on manipulations, not just access times.

The typical += construct used so often with tuples VS list methods like append(), for example.

In a trivial application everything is trivial. My point was the development of sound habits and thinking patterns -- in particular identifying what the differences between tuples, lists and dictionaries actually mean.

This gets into a way different discussion -- but the habit of instantiating everything as a class has, in my experience, been a bad sign but one heavily promoted by the "let's replace C with Java everywhere in CS 101 courses!" which was just before the level of freshly minted graduate programmers took a seriously dive.

We've argued this endlessly for the last few years, though. The mailing list archives are replete with everyone from me to deh Linus Hisself ranting about this, so I won't extend it here.

Some use cases benefit from object orientation (simulations and games in particular). Most don't. But that wouldn't have sold very well, so its not what the market, bookstores or academia got. What's funny is some iconic authors like Bruce Eckel and Herbert Schildt argued against the complete rush to OOP, but they were compelled to write OOP books by their publishers because they simply weren't going to get paid to write anything else. One of the two, don't remember which, gave an interview a while back in which is totally blasted Java, despite having written the canonical study book for it.

Blah blah. Old guy neckbeard anger...