3 ms·
> In my opinion, it's great that there are such few options to express this operation, and that both cases are eminently readable. There are lots of ways to do
by Y_Y 2y ago
> In my opinion, it's great that there are such few options to express this operation, and that both cases are eminently readable.
There are lots of ways to do this in Python. That's not only fine, it's inevitable.
Here's a burnt-out PhD level one using highly pythonic paradigms:
def fac(n):
return eval("*".join(str(1+a) for a in range(n))
- oersted 2y agoI have never seen a codebase that uses eval, it's considered more toxic than goto. Of course there are more ways, but I would definitely qualify this as "unreasonably convoluted".
- Y_Y 2y ago> it's considered more toxic then goto Again I ask, considered by who? This is the kind of language that wikipedians would call "weasel words". Of course you shouldn't misuse eval or goto, and it's fine to have a rule of thumb to discourage it. What's not fine, and strikes me as no better than superstition, is to make vague "everybody knows"-type statements that convey almost no information. If it's bad you should be able to say (or provide reference to) specifically how it's bad and what convinced you this was the case. And yes, I deliberately wrote a perverse function because it was funny, but if you did a real fold instead of my fake one with strings then it wouldn't be so perverse. And wasn't it more pythonic to use a generator? Not embracing Perl's tmtowtdi is fine, but until you solve the halting problem some people will write "x+x" and some will write "2*x" and some will write "x<<2" and those can't sensibly be unified.