4 solutions to leetcode 202. Happy Number have almost same performance
Solution #2:

class Solution2:
    def isHappy(self, n):
        # ...
        while n != 1:
            if n in s: return False
            # ...

    return n == 1


You are looping while n != 1, without any break statements. There is no need to test n == 1 at the return statement at the end.  Just return True.



Solution #3 returns None if 0 is given as input, instead of returning True or False.



Solution #4 becomes an endless loop if 0 is given as input.

Are there any other stopping conditions other that n == 0, n == 1 or n == 4?  It isn't clear that all unhappy numbers result in a loop containing the value 4, so the validity of this approach is in question.

Update: Actually Wikipedia provides a clear argument that unhappy numbers will arrive in a loop containing the value 4, so this approach is valid, but should included a comment with a link to that proof.



In all your solutions, your loop is testing at least two conditions, such as both n != 1 and n is s.  Why not initialize s to contain a 1 (or even just leave it as an empty set), and then only test n in s.  No special cases.

def is_happy(n):
    s = { 1 }

    while n not in s:
        s.add(n)
        n = sum(i * i for i in map(int, str(n)))

    return n == 1


Update:

Since Wikipedea has proof that all positive unhappy numbers end in the sequence 4 → 16 → 37 → 58 → 89 → 145 → 42 → 20 → 4 → ..., and happy numbers end in the sequence 1 → 1 → ..., you can create a set of these termination values (including 0 → 0 → ...), and no longer needed to maintain the set of "seen" values.  By using all numbers in the unhappy loop, we can terminate the search up to 8 iterations earlier over just checking for n == 1 and n == 4.

def is_happy(num):
    # See https://en.wikipedia.org/wiki/Happy_number#Sequence_behavior
    terminal = { 0, 1, 4, 16, 20, 37, 42, 58, 89, 145 }

    while num not in terminal:
        num = sum(i * i for i in map(int, str(num)))

    return n == 1




Finally:


follow the PEP-8 standards (avoid mixedCase function/method names),
Stop writing classes!