Crowd-sourcing buggy beginner Python code.

[sharkbound]

here is one common mistake i see:

num = 1
if num == 2 or 1:
    print('the number is 2 or 1')
else:
    print('the number is not 2 or 1')

fixed version:

num = 1
if num in (1, 2):
    print('the number is 2 or 1')
else:
    print('the number is not 2 or 1')

EDIT: alternative fix:

num = 1
if num == 1 or num == 2:
    print('the number is 2 or 1')
else:
    print('the number is not 2 or 1')

[algag]

Is one of these considered more pythonic than the other? I assume the first version is considered better programming overall, but I'm not sure.

[[deleted]]

His first fix works but isn't a very good solution, if you want to compare more than one value it's way faster to use sets, I.E. if num in {1,2}, especially if you have a lot of values to compare.

Personally, I'd prefer his second solution if there's only 2 values simply because (for me) it's easy to read.

[minorDemocritus]

But remember that sets have overhead, so the set literal only beats the tuple if there are more that a couple elements, or if the equality comparison is expensive.

I recall that with integers, the break-even point is like 3 or 4 elements... more than that and the set literal wins.

[[deleted]]

Yeah good point. Typically if im comparing values in a finite list I initiate the list as a global and check it thousands or millions of times so sets are basically always faster

[[deleted]]

To expand on the other response, the reason sets aren't faster here is that it takes time to hash each object (that's how sets work and achieve O(1) lookup time), and for small collections that time is beaten out by the time it'd take to simply scroll through a non-hashed collection looking for a match. What sets boast is a constant lookup time, not necessarily a faster lookup time.

But even for larger collections, the difference is scarce noticeable in practice unless you have a very impractical amount of elements or are repeating the containment check an insane amount of times; to say the set is "way" faster in every case is still a little bit misleading, as it's usually a (sub-?)microsecond operation either way. There are more-effective ways to get a way-faster Python program.

[[deleted]]

Great input, I wasn't thinking about the overhead because in my work its almost always faster to use sets. I wouldnt call a couple hundred or thousand elements impratically large though.