You might have a point with the 'x' variable, but that's the default argument of the kata as accepted, so I'm personally not inclined to fault the warrior. As for 'f' as a bad name, I disagree.

It is a pythonic axiom that 'Readability Matters'. If 'f' were to be carried throughout a long function, I would say a more verbose name would be preferred, however in this instance it is a throwaway variable, used only within the context of the list comprehension. Further, PEP-8 standards require all code lines to be a maximum of 79 characters. As written, the line is 40 characters long (36 in the code + 4 in the indent). This particular comprehension could be accomplished with somewhat longer names, but what if it was one or two indentations deeper or had more involved logical statements? As a general rule, long names in a comprehension will balloon out of control very quickly. There's no need to stretch a line for throwaway variables.

I agree 'x' and 'f' are terrible names, particularly for readability

why? is it because it doesn't reflect any meanings?

pretty much, unless there is margin for huma error, or if you are building a desktop app, or a web app, when there is not much room for error as in a simple script I see no need,, It all depends on what you are programming and if there is considerable room for error, Alsays put error handlers in for human input, them humans and their input I tell ya what

Agree it's not best practices, but you have to admit it's kind of nice to not have to worry about what kind of nonsense you might have a user pass to you.

This Kata is based on Haskell's Maybe monad though, which is meant for cases where you don't really care about the type of exception. When you do care, something like the Either monad would be a better pick.

Thanks for the tip. Am an offender in this case.

I disagree -
try running with an except ValueError, and you won't pass the submitted test, as one of the tests is a list passed in -

neh you do not have to display the exception error here it is striaght forward, if there was differnt kinds of exceptions that could have been thrown then the specifics would come into play, but it is actually a great advantage of python. if you were to display the error, it is only one kind of error so it is not worth the time to catch an eception name if the exception is already known. now for different errors
try this: except: if not this pretty much boolean exception handling

As one of the offending coders, I concur. I think codewars needs a 'Would be Used in Production' button for well-documented, efficient, corner-case-handling code.