I know it's a two year old question, but I'll bite, as I wrote a very similar solution (technically, it's two lines, not one).

In this case, it was a pretty simple problem and the code was initially written on one line. It would have taken more time and effort to deconstruct it into multiple lines. Arguably, if you spread it over as many lines as possible, it would have been harder to read, so you have to decide what stays together on one line and what splits up. That all takes time and mental effort - and it's just another 6kyu kata that I just want to tick off.

Other times, I take an initial long, rambling, solution and cram it onto one line, often simplifying it in the process. In those cases, I am just having fun - trying to make it concise and elegant. If it was production code that another programmer would have to work with in the future, I might still do this - in order to see what can be simplified - but then I would rewrite it in a clear, unambiguous and self-documenting manner (which would usually necessitate it being multiple lines).

You are right. I fixed it.

Not sure if you're trolling or not but, you know you could just scroll through it by having your pointer outside the solution box.

If we are going to be critical of solutions, yours is pretty junky. lambdas inside lambdas, list instead of tuple... You failed best practices, arguably 3 times, in one line.

Your version can only be scaled by appending more crap into your one bad line. Mine is scaled by arguments, which means the functional part of my code never needs to change. Also, I have reused br_and to solve around 10 katas... all resulting in a one line answer that has the same interface every time. So, as far as unnecessary goes, it keeps getting reused. Your code isn't reusable, at all. If we really want to talk about unnecessary, the entire kata is unnecessary. My version provides a reusable utility, yours is just 100% useless for anything other than solving this one kata. It's not even a good python example.

Not at all.. yours includes and involves extra unnecessary steps. It's needlessly more confusing in an attempt at needless universality.

Gotcha! Thx anyhow

I'm late to answering your question, but it matters little, because I don't know why I used generators instead of lists. The way I did it just seemed like a good way to me. There wasn't really any "decisions".

Great readability! Can you share why you opted to use generators instead of lists for example? Is it faster, better practice, or?

#11b33/3q9:0z:vV

i can see the appeal of writing code like neutron star material

your code is very concise and elegannt

I don't know if it is really "cheating", per se' but, it isn't the "well-known" equation. As far as "more thought" is concerned, I can't say I agree. This just keeps incrementing i and adding it to n until n is not less than h. If the steps of a range were more dynamic I could have gotten the same answer from the final length of a range. Actually, that's exactly how I came up with this solution ~ i is the increasing "length" of the "range" and n is incrementing steps, hypothetically.

How is this cheating? For me it requires more thought that just using well known equation.

What's the appeal with cramming all of this on one line? You have the exact same solution as pretty much everybody that answered this question, except yours is a nightmare to read. Look at my solution. It does all of the exact same stuff as yours, but it would only take someone about 8 seconds to read and understand mine. Cramming everything on one line does not make it clever.

Yes, you can put anything in a list. What is it that you really want to do? What problem are you trying to solve with this?

In Python can you have a list where some items in it are lists are some items are numbers?

If so then my solution won't work.