Could be shorter creative solution for Flatten a List by veky - python coding challenges

Enable Javascript in your browser and then refresh this page, for a much enhanced experience.

Could be shorter solution in Creative category for Flatten a List by veky

flat_list=f=lambda d:0*d==0 and[d]or sum(map(f,d),[])#)][,)d,f(pam(mus ro]d[dna 0==d*0:d adbmal=f=tsil_talf
#Tweet? Palindrome? Solution.

April 24, 2014

Comments:

nickie on April 24, 2014, 10:18 p.m.
Haven't I upvoted this one before? Let me see, what had I given it? Ah, it was a +2. Now it's going to be a +3 because of the palindrome and the provocative comment which bring it to 138 characters, if I counted right... I would have been tempted two to add two more characters and make it 140... :-) <pre class='brush: python'>#Tweet? #Palindrome? #Solution. </pre>

veky on April 24, 2014, 11:24 p.m.
Well, I didn't know how much is \n worth, and didn't really want to go all the way to 140, just to show there's still room for growth. (#tweet? was a pun on hashtags, of course.)

DiZ on April 29, 2014, 2:17 p.m.
'd*0==0'... Amazing, really. By the way, 1 more character to delete: space between 0 and 'and' ;)

veky on April 29, 2014, 6:30 p.m.
<blockquote> space between 0 and 'and' ;) </blockquote> Amazing, too. :-) Yes, I know about that, but somehow missed that here. Anyway, tweets are looong, there's plenty of space. ;-) Your efforts are also cool. ;-) d*0==0 is nice, but see comments on the old task... d<[] is even more brainbending, though it doesn't work on Py3k. :-/

iafilatov on May 4, 2014, 8:42 a.m.
I wonder if <pre class='brush: python'>sum([[1], [2], [3]], []) -> [1, 2, 3] </pre> is a side effect or an expected behavior of sum()? The docstring says that the it expects numbers in the iterable: <blockquote> Return the sum of an iterable of numbers (NOT strings) plus the value of parameter 'start' (which defaults to 0). </blockquote> Interesting that it can be tricked to "add" lists, but not strings: <pre class='brush: python'>sum(['wo', 'rld'], 'hello') -> TypeError: sum() can't sum strings [use ''.join(seq) instead] </pre>

veky on May 5, 2014, 5:24 a.m.
Hm. When you build your entire philosophy around duck typing, documentation is really hard to write to be both correct and easily understandable. Please read <a href="http://www.drmaciver.com/2013/07/a-case-study-in-bad-error-messages/">http://www.drmaciver.com/2013/07/a-case-study-in-bad-error-messages/</a> (and comments too, especialy mine:) for a more acute example. The point of duck typing is that perfect documentation looks precisely like the code itself - you just do this, this and this, and if it works, you have the result. If it doesn't, you don't. And that, of course, isn't very helpful. Much more helpful is to just write about the most common use case. And that is surely to sum numbers (or bools, which are numbers too;-P). However, that leads naturally to another question: why does it specifically mention that it doesn't work for strings? "Because it doesn't work for strings" is not really a useful answer. :-) But it's correct. Why doesn't it work for strings, then? Because they were specifically excepted in the code. There is a line in source code of sum, that specifically tests for str (and bytes,...), and raises TypeError if it encounters them. If it doesn't, it proceeds to code that would work even for strs. Why is that? "Because the way it's implemented would be horribly inefficient for strs" (see "Schlemiel the painter's algorithm") is, again, not really an answer, although it's correct. Surely, if you already check for strs, you could delegate to "".join instead of raising TypeError, right? Well, that question is hard. It took me almost a year to finally wrap my head around it. But it makes sense historically. :-)

iafilatov on May 5, 2014, 10:27 a.m.
Well, [a] + [b] also gives us a new list. And talking about horrible inefficiency: <pre class='brush: python'>l = [[1] for i in range(100)] def f1(): return sum(l, []) def f2(): res = [] return res.extend(l) def f3(): res = [] for e in l: res.append(e) return res timeit(f1) -> 28.424042056081817 timeit(f2) -> 0.4858708551619202 timeit(f3) -> 5.967408919939771 </pre>

veky on May 5, 2014, 10:37 a.m.
<blockquote> Well, [a] + [b] also gives us a new list. </blockquote> Yes, but lists are not so often used in sum, and moreover there is no corresponding builtin (as "".join is for strs). As for your timings... sorry, you really should learn much more about Python before using timeit. For instance, are you even aware that your three functions do completely different things, and return three different values? :-P

iafilatov on May 5, 2014, 12:47 p.m.
Crap, I pasted the wrong stuff... Here: <pre class='brush: python'>def f2(): res = [] res.extend(ee for e in l for ee in e) return res def f3(): res = [] for e in l: for ee in e: res.append(ee) return res def f4(): res = [] for e in l: for ee in e: res += [ee] return res def f5(): res = [] for e in l: for ee in e: res = res + [ee] return res def f6(): res = [] for e in reversed(l): for ee in e: res.insert(0, ee) return res timeit(f2) -> 8.464586924994364 timeit(f3) -> 9.77216490288265 timeit(f4) -> 13.938408269081265 timeit(f5) -> 38.05730778700672 # even this abomination is faster (because # it's not creating new lists like crazy?) timeit(f6) -> 21.088412085082382 </pre> These, I think, are what an Average Joe would write (except f6()). I mean, it'd even take time to invent a way to do it less efficiently than sum() (because ducks like it unspecific). I'm comparing from the point of view of a guy that just wants to "make a list from lists in this list". For this exact guy (for whom else? "Thou shalt not add strings" is like everywhere) sum() forbids strings, but strangely, not lists. Is it really because people are unlikely to do it anyway? <a href="http://hg.python.org/cpython/file/57c157be847f/Python/bltinmodule.c#l2412">And hey, they were actually thinking about lists.</a>

veky on May 5, 2014, 2:24 p.m.
I don't see what you're trying to say, except what I already said. First, clueless people usually try to use sum for strs much more than for lists. Second, "".join is perfectly fine for that use case, and generalizes in more useful way (you can insert something in between items).

iafilatov on May 5, 2014, 2:41 p.m.
Well, after thinking about it a bit... not much. Initially I thought about sum() as simply the best and easiest way to add many numbers. I would've never thought of stuffing lists or strings in it (yes, surely someone would). Now I see it as a better way to do something like f5(), which works even faster for some objects. As for strings, is there such a language, that after it people are likely to sum() them in Python? Hm...

veky on May 5, 2014, 2:48 p.m.
Well, I guess that there is a reason that even Java, with its strict "no overloading" policy, made an exception for adding strings. People, especially newbies, really do think of concatenation as "string addition".

taras-sereda on Feb. 8, 2015, 10:33 a.m.
Veky, it's fantastic solution! As usual educational for me. Thanks.

veky on Feb. 8, 2015, 11:29 a.m.
I just wanted to say that 140 characters is really too many. :-D

taras-sereda on Feb. 8, 2015, 11:32 a.m.
well, for me 140 it was no to much, hope that one day I'll be able to apply these words for my solutions as well. :)

fuzzy-focus on Aug. 13, 2015, 6:24 p.m.
The idea with the sum is interesting, would not have thought of it but it didn't surprise me. but <pre class='brush: python'>0*d==0 and[d]or X </pre> blew my mind. I never thought of the boolean operators as being able to do branch-like operations without using an if statement.

veky on Aug. 13, 2015, 7:41 p.m.
Hm. That's old. People were using <pre class='brush: python'>a and b or c </pre> as a substitute for ternary operator (if a, then b; else c) for a long time, even in Perl era. In fact subtle failure of such code (when b is false) made Guido add <pre class='brush: python'>b if a else c </pre> as new syntax to the language. See <a href="https://www.python.org/dev/peps/pep-0308/">https://www.python.org/dev/peps/pep-0308/</a> for a bit of history. :-) <hr /> The part with multiplying by zero was probably my invention - but still, detecting types by mapping them to singular values using distributive operations is a relatively standard mathematical trick [see, for example, homotopy type theory:]. :-)

fuzzy-focus on Aug. 14, 2015, 7:42 a.m.
This was the first time I saw it. Didn't do enough coding back in the Perl days to really find things like this. And in Python I just always assumed everything that is an argument to a logical operator such as 'and', 'or',... is basically internally processed like "True if X else False". Which is ridiculous in hindsight, but that was my (unchecked) assumption.

veky on Aug. 14, 2015, 8:09 a.m.
"internally processed" is not a bad intuition. Keywords usually take what they need from an object (`for` takes `iter`, `and/or/if/elif` take `bool`, `with` takes `enter` and `exit`, `except` takes `type`...) and use that. But when producing output, they usually leave the object alone: <pre class='brush: python'>try: blah except NameError as e: print(e) </pre> `e` in the above is not just its `type` (`NameError`), but a concrete instance with a message like `name 'blah' is not defined` -- although it is caught as just `NameError`. In the same way, <pre class='brush: python'>5 or 7 </pre> `5` is not just its `bool` (`True`), but a concrete number with more information in it -- although it is branched as just being true. <hr /> I guess people don't perceive it that way since in many other languages, `and` and `or` are just operators (`&&` and `||` in C, for example), and operators are just methods. As such, they usually "forget" extra information and coerce their operands to output: <pre class='brush: python'>True * True </pre> -- you get `1`, not its `bool` (`True`), although both operands are `bool`s. But even in languages like C, they are not really simple methods, since they make sequence points and have special evaluation rules (they don't necessarily evaluate all their "operands"), which suggests they really are the program flow-controllers, same as `if` for example. Python is stricter with that distinction, and uses keywords exclusively for flow-controllers, while reserving symbols only for method-like operators.

fuzzy-focus on Aug. 14, 2015, 9:15 a.m.
Good to know, very educational. Thanks for that.

viktor.chyrkin on Jan. 23, 2022, 3:16 p.m.
When does this become False? and [d]

veky on Jan. 23, 2022, 3:42 p.m.
It doesn't, that's why `or` works. In fact, the reason why Guido added `b if a else c` is that `a and b or c` (as it was written previously) could mask a bug if `b` could be false. Se the above comments too.

viktor.chyrkin on Jan. 24, 2022, 12:21 a.m.
Thanks. Good to know.

xilric on Feb. 29, 2024, 11:18 a.m.
you're sick F09F

veky on March 1, 2024, 9:28 a.m.
Thank you. :] What's F09F?

List, list and list again

0 %

You ClassRoom Demo is Ready With the new tool CheckiO ClassRoom, you will be able to analyze your students' progress, have your own leaderboard, change missions order on the map, and so on.