sum (x:y:z:[]) = sum [x, y, z]
(-) 74 = (74 -)
flip (/) 30 = (/ 30)

Use an as-pattern here to avoid re-cons after your cons pattern match:

solution s@(first:rest) suffix
    | s == suffix = True
    | otherwise   = solution rest suffix

Pointfree go brrrrr...

This is clearly wrong, how did this even get approved? oddOrEven [0, 1] returns "even".

Top one is actually quite good. If it were for real, I would write it as a proper named function. That way is real nice for avoiding duplication, and something I didn't think of.

def is_palindrome(s: str):
    processed_text = ''.join(c for c in s.upper() is c.isalpha())
    return (lambda x: x == x[::-1])(processed_text)

100% cursed. Love it.

What? Well, yes, that's true, but I didn't write this one. Just pointed out that shortcoming.

Fun fact - I have 0% chance of figuring out how this works.

24 characters shorter, and I respected proper formatting rules (still a joke solution though).

Fair enough reasoning, I suppose.

This is a bad idea - what if someone did something like this: Calculator("+ 0;", "0 ", "print('Thanks eval')")? It may be shorter but you have just opened up this simple program to vulnerabilities.

Gross, good luck with maintainability or comprehension. This isn't code golf.

Better than my own, very good

If I was worrying about the cost of operations like division, I wouldn't be using Python.

If you know what format the temperature is coming in already, you can just check it against the type to convert to. There is no such thing as "both". It is one or the other. Whenever you use both, the calculation for the same type of temperature will always be wrong (input fahrenheit, convert with "both", output fahrenheit will be different because it was treated as celcius).

EDIT: Ok, I see - it is tested upon and expected to work that way. Still a dumb idea. One will always be wrong, why bother.