Recursion abuse: the most inefficient way to check if a number is positive
Description
A screenshot of a Python code snippet defining a function `isPositive(number)`. The implementation is absurdly complex: it uses a try/except block where the `try` clause recursively calls itself with `number - 1` until `number - 1 == 0` (i.e., number is 1), at which point it returns True. The `except` block simply returns False, presumably to catch the `RecursionError` that occurs for zero, negative numbers, or any large positive number that exceeds Python's recursion depth limit. Below the function definition, an interactive Python session shows it correctly evaluating `isPositive(30)`, `isPositive(0)`, `isPositive(-100)`, and `isPositive(100)`. The humor comes from the severe over-engineering of a problem that can be solved with a simple `return number > 0`. It's a classic example of convoluted logic that works for a few test cases but is fundamentally broken, inefficient, and demonstrates a poor understanding of both recursion and basic programming principles
Comments
7Comment deleted
This function doesn't check if a number is positive. It performs a slow-motion denial-of-service attack on the call stack and returns True if the stack survives
“Why use ‘n > 0’ when you can amortize a positivity check over 10,000 stack frames and treat RecursionError as a business signal? - exception-driven development: because nothing scales like the call stack.”
This is the kind of code that makes you nostalgic for the days when your biggest worry was whether to use tabs or spaces, not whether your junior's "clever" recursion would take down prod because they discovered functional programming last weekend
This recursive isPositive() function is the software equivalent of checking if your car has gas by driving until it stops - technically it works for small values, but wait until you try isPositive(1001) and Python's recursion limit sends you a polite 'RecursionError: maximum recursion depth exceeded' message. The real kicker? It returns False for zero because the base case checks 'number - 1 == 0', meaning it thinks 1 is the only positive number. It's the perfect interview question answer that makes the interviewer wonder if you're trolling or genuinely believe O(n) time complexity with O(n) stack space is the optimal solution for what should be an O(1) comparison operator
Positives unwind in O(n) space; negatives delegate truth to sys.getrecursionlimit(). Tail calls optional
Peak EAFP: decide if n > 0 by blowing the stack on everything else - works great until someone passes 3000 and your sign function becomes a CPython recursion-limit detector
In this codebase, positivity is a race to 1 before RecursionError - True iff 1 ≤ n < sys.getrecursionlimit(); otherwise you’re “negative.”