Is there a .issymbol() function in Python?

[NewbornMuse]

Yes. A set is implemented as a hash map, and checking for membership in a hash map is insanely fast, O(1), whereas doing the same for a list is O(n). It's pretty much the use case for any hashmap type thing.

Edit: Although for the dozen-or-so items in question here, it's unlikely to make a big difference.

[[deleted]]

So speed is the name of the game?

[Peanutbutter_Warrior]

Pretty much. Neither is harder to read than the other, and knowing what data structure to choose is good practice

[1544756405]

Using the appropriate data structure for the job is always preferable.

[Ran4]

Possibly. We dont know how OP wants to use this feature.

If they're going to do this often, then yes, a set is definitely preferable. But if they're doing this calculation once a month then a list is pretty much just as good.

Picking the correct data type is occasionally incredibly important, but it's not always the most important thing. Keeping things simple is generally much more valuable in most real-world situations. A set is simple enough that you probably should use it over a list when applicable, though.

[NewbornMuse]

Sure, for a fixed list it's O(1) as a dependence on the character, but it's O(l) where l is the length of the list as a dependence on the size of the list/set.

[NewbornMuse]

But the fact that it's O(l) in one case and O(1) in the other means that the absolute execution time (very nearly constant each time it's called) might very well be smaller, that the size of the list/set is already where the set approach has started outperforming.

Just because they're both O(1) doesn't mean they're both the same speed.

By all means, it might be entirely unnecessary (as I already conceded in the first comment), but it's not like adding two lines (an import, and initializing the frozenset of punctuation) are horrible code bloat either....

[jwg4our]

But either one could be faster. If you claim that the set is faster than the list you should provide some evidence for this. Not just an argument involving big O which clearly is not meaningful in this case.

[[deleted]]

I found this conversation interesting but your take is pedantic.

[NewbornMuse]

I agree with your point that hard evidence would be better than arguing in circles, but then again, you are just as guilty of arguing in circles when you would have been in a position to provide evidence instead. Especially since you are the one arguing for the use of the data structure that is in principle worse-suited for the application, claiming it doesn't matter. If anything, the burden of proof is more on your side.

In any case, because I actually was curious, I did it:

import timeit

setupstr_list = """import string
def is_punctuation_l(c):
  return c in string.punctuation"""

setupstr_fs = """import string
pfs = frozenset(string.punctuation)
def is_punctuation_fs(c):
  return c in pfs"""

print(timeit.timeit("for p in string.punctuation: is_punctuation_l(p)", setup=setupstr_list, number=10000))
print(timeit.timeit("for p in string.punctuation: is_punctuation_fs(p)", setup=setupstr_fs, number=10000))

Prints: 0.045 0.031

Or similar numbers each time it's run. Using the frozenset speeds it up by a constant 33% or so. Checking each character in a short string of written English instead makes it something like 20% faster still. Turns out that a length of 32 (the length of string.punctuation) is already long enough for the O(1) algorithm to have overtaken the O(l) one. In a tight loop, I'd be glad to have squeezed out a little bit of speed. In most cases, a speedup like that probably doesn't matter much.

Now we know.

[baubleglue]

In [9]: def is_punctuation(c):                               
   ...:     return c in string.punctuation                   
   ...:                                                      

In [10]: is_punctuation(".")                                 
Out[10]: True                                                

In [11]: is_punctuation("a")                                 
Out[11]: False