41–50 of 114 posts
Earlier quoted context omitted.
I would also, I love this sort of thing. How about: >>> some_boolean = False >>> ["Thing 1", "Thing 2"][some_boolean] "Thing 1"
Yeah, but unlike the hack in the article, the more readable version of that code, "Thing 1" if some_boolean else "Thing 2" is also almost twice as fast(775 vs 1340 ns, on my machine).
We all love short and fast. But this is definitely an interesting approach. I'd love to see similar approaches to problems if you guys can point out to some.
We all love short and fast. But this is definitely an interesting approach. I'd love to see similar approaches to problems if you guys can point out to some.
I would also, I love this sort of thing. How about: >>> some_boolean = False >>> ["Thing 1", "Thing 2"][some_boolean] "Thing 1"
I'm glad Clojure has top-level support for this operation... it's quite flexible too, and the presence of partition-all makes it explicit what you should expect if the sequence doesn't evenly partition. user=> (partition 3 [1 2 3 4 5 6]) ((1 2 3) (4 5 6)) user=> (partition 3 [1 2 3 4 5 6 7]) ((1 2 3) (4 5 6)) user=> (partition-all 3 [1 2 3 4 5 6 7]) ((1 2 3) (4 5 6) (7)) user=> (partition 3 3 (repeat 0) [1 2 3 4 5 6…
Earlier quoted context omitted.
I would also, I love this sort of thing. How about: >>> some_boolean = False >>> ["Thing 1", "Thing 2"][some_boolean] "Thing 1"
the problem with this expression is that it doesn't "short circuit". Both "Thing 1" and "Thing 2" (in this cases object, but the can be function calls) are evaluated before the "some_boolean" usage.
In particular, if you want the side effects of both operations. Trying to write multiple things while checking if any of them failed, for instance.
Earlier quoted context omitted.
I'd be surprised if my way is slower. Any time you unpack into a function such as zip() python has to create an intermediary list to store all the results before calling the function.
Exactly, I would be very surprised if the zip version was faster. One of the first steps to optimization in python is moving everything you can to generators and using of itertools. The OP's question of is this genius or bad is clear in that regard: it is bad, due to not being the proper optimization direction, but it is interesting.
The part that annoys me is that the docstring mentions "dictionaries" when I see no `dict`s.
I'm glad Clojure has top-level support for this operation... it's quite flexible too, and the presence of partition-all makes it explicit what you should expect if the sequence doesn't evenly partition. user=> (partition 3 [1 2 3 4 5 6]) ((1 2 3) (4 5 6)) user=> (partition 3 [1 2 3 4 5 6 7]) ((1 2 3) (4 5 6)) user=> (partition-all 3 [1 2 3 4 5 6 7]) ((1 2 3) (4 5 6) (7)) user=> (partition 3 3 (repeat 0) [1 2 3 4 5 6…
λ> chunksOf 3 [1..12]
[[1,2,3],[4,5,6],[7,8,9],[10,11,12]]
I think the code is pretty ok, except for the stupid name, docstring and that it is a method and not a free function. def chunks(seq, n): "groups the elements of the seq into a list of n-sized chunks." return zip(*[iter(seq)]*n)