Rather depends if we can trust that it's Python's "filter" or if it's another language you're making look Pythonic, and we don't know who implemented filter/2 or how.
- The first one might be an in-place filter and mutate "numbers", the second one definitely isn't.
- The first one might not be Python's filter and might be a shadowed name or a monkeypatched call, the second one definitely isn't.
- The first one isn't clear whether it filters odd numbers in, or filters them out, unless you already know filter/2; the second one is clear.
- The first one relies on you understanding first-class functions, the second one doesn't.
- The first one isn't clear whether it relies on `numbers` being a list or can work with any sequence, the second one clearly doesn't use list indexing or anything like it and works on any sequence that works in a `for` loop.
- The first one gives no hint what it will do on an empty input - throw an exception, return an error, or return an empty list. The second one is clear from the patterns of a `for` loop.
- The first one has a risk of hiding side-effects behind the call to filter, the second one has no call so can't do that.
- Neither of them have type declarations or hints, or give me a clue what will happen if "numbers" doesn't contain numbers.
- The first one isn't clear whether it returns a list or a generator, the second one explicitly uses () wrapper syntax to make a generator comprehension.
- The first one has a risk of hiding a bad algorithm - like copying "numbers", doing something "accidentally n^2" - while the second one is definitely once for each "n".
Along the lines of "code can have obviously no bugs, or no obvious bugs" the second one has less room for non-obvious bugs. Although if the reader knows and trusts Python's filter then that helps a lot.
Biggest risk of bugs is that odd(n) tests if a number is part of the OEIS sequence discovered by mathematician Arthur Odd...
> "Neither of them have type declarations or hints, or give me a clue what will happen if "numbers" doesn't contain numbers."
bools in Python are False==0 and True==1, and I'm now imagining an inexperienced dev believing those things are numbers and has no idea they could be anything else, and is filtering for Trues with the intent of counting them later on, but they messed up the assignment and instead of 'numbers' always getting a list of bools it sometimes gets a scalar single bool outside a list instead. They want to check for this case, but don't understand types or how to check them at all, but they have stumbled on these filter/loop which throw when run against a single answer. How useful! Now they are using those lines of code for control flow as a side effect.
This is ridiculous. You can assume that you know what language you are reviewing/working in (sorry, I forgot to mention that the example is in Python). I can remember cases when I was not sure what [human] language I thinking in, but I don't remember a single case when there was a confusion what programming language I'm working in (it is not a factor in cognitive load).
filter is a builtin name in Python. There is no confusion here in practice. Static checker such as ruff will tell you if you attempt it accidentally. It is the first rule: A001 builtin-variable-shadowing.
If you are a noob the second variant may be easier to grasp. The first variant has less moving parts.
- The first one might be an in-place filter and mutate "numbers", the second one definitely isn't.
- The first one might not be Python's filter and might be a shadowed name or a monkeypatched call, the second one definitely isn't.
- The first one isn't clear whether it filters odd numbers in, or filters them out, unless you already know filter/2; the second one is clear.
- The first one relies on you understanding first-class functions, the second one doesn't.
- The first one isn't clear whether it relies on `numbers` being a list or can work with any sequence, the second one clearly doesn't use list indexing or anything like it and works on any sequence that works in a `for` loop.
- The first one gives no hint what it will do on an empty input - throw an exception, return an error, or return an empty list. The second one is clear from the patterns of a `for` loop.
- The first one has a risk of hiding side-effects behind the call to filter, the second one has no call so can't do that.
- Neither of them have type declarations or hints, or give me a clue what will happen if "numbers" doesn't contain numbers.
- The first one isn't clear whether it returns a list or a generator, the second one explicitly uses () wrapper syntax to make a generator comprehension.
- The first one has a risk of hiding a bad algorithm - like copying "numbers", doing something "accidentally n^2" - while the second one is definitely once for each "n".
Along the lines of "code can have obviously no bugs, or no obvious bugs" the second one has less room for non-obvious bugs. Although if the reader knows and trusts Python's filter then that helps a lot.
Biggest risk of bugs is that odd(n) tests if a number is part of the OEIS sequence discovered by mathematician Arthur Odd...