Very cool. However it’s inefficient, the intermediary list isn’t needed, and you can just use a generator comprehension. (You can just delete the square brackets and change nothing else since Python is nice about that)
oh, of course! it’s the unnecessary intermediate list that makes it inefficient, not the launching of an entire interpreter toolchain on every single function call 😆
though, i wonder if there is a sufficiently optimizing compiler might be able to actually remove the intermediate string and convert this to a tight loop, without allocation and only using numbers, no strings. it wouldn’t be impossible that ghc could do it, if eval is written in haskell
I'm usually bad a reading other people's code. But I can actually read this one. It isn't that bad.
It produces a string representing numbers in a sequence being multiplied together, like "1*2*3*4[...n...]"
Comments
it's always like that working on a project with ppl who are mathematicans first and software devs second
however the `range` constructor performs checks so any non-number will produce an exception
Other than that looks fine, ship it
It produces a string representing numbers in a sequence being multiplied together, like "1*2*3*4[...n...]"