I like to map it, map it clear solution for Split Pairs by veky - python coding challenges

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

I like to map it, map it solution in Clear category for Split Pairs by veky

import itertools, operator

def split_pairs(a):
    it = itertools.chain(a, '_')
    return map(operator.add, it, it)

June 10, 2019

Comments:

mn4740 on April 17, 2020, 10:29 p.m.
Beautiful and clever use of generators!

Sasha_Geometricheskij on May 17, 2020, 3:58 p.m.
Did u miss a slice?

Sasha_Geometricheskij on May 17, 2020, 4:01 p.m.
sorry, i get it)

veky on Aug. 27, 2020, 6:31 p.m.
Yeah, I understand blind smileys. :-D

veky on May 17, 2020, 4:03 p.m.
As you see, I didn't miss it at all. :-D (Relevant joke: <a href="https://unijokes.com/joke-2789/)">https://unijokes.com/joke-2789/)</a>

Sasha_Geometricheskij on May 17, 2020, 4:12 p.m.
))

mohammad.moaddi on Aug. 25, 2020, 11:12 a.m.
Lol

Evelyn_He_Xinyi on Sept. 24, 2020, 5:01 a.m.
Not sure why but it doesn't work for me:(

veky on Sept. 24, 2020, 5:37 a.m.
What do you mean by that? What message do you get?

Evelyn_He_Xinyi on Sept. 24, 2020, 9:36 a.m.
Thanks for asking! I should've posted the message here. I get <map at 0x10836ceb8> from below. Do you know why? <pre class='brush: python'>import itertools, operator def split_pairs4(a): it = itertools.chain(a,'_') return map(operator.add,it,it) split_pairs4('abcdedf') </pre>

veky on Sept. 24, 2020, 11:46 a.m.
Yes, because you return a map. :-) Look, basic tenets of bug reporting: <ul> <li>what did you do?</li> <li>what result did you get?</li> <li>what result did you expect?</li> </ul> After prodding by me, you did first and second (thank you). But the third still eludes me. :-) Maybe you expected a list?

Evelyn_He_Xinyi on Sept. 24, 2020, 2:27 p.m.
Thanks for prodding, again!=D I got it now, was missing the list() in my return. Appreciate it Veky!

mailsiraj on Nov. 17, 2020, 3:19 a.m.
Hi Veky, can you please explain how the map function works here? You are passing the same iterator twice, but how does items alternatively? I googled read about chain, map and operator.add, but still could not understand how this is working?

veky on Nov. 17, 2020, 8:33 a.m.
I assume you know that `map(f, a, b)` is <pre class='brush: python'>a, b = iter(a), iter(b) while ...: yield f(next(a), next(b)) </pre> Then, if `a` and `b` are already iterators, first line doesn't do anything. And if `a` and `b` are the same iterator, `next` is called twice on it in every pass.

mailsiraj on Nov. 25, 2020, 9:27 a.m.
Thanks veky for the explanation. The trick is that next is called twice. I guessed it, but I wanted to be sure. Thank you so much. Now I see the beauty of the solution.

veky on Oct. 1, 2021, 6:33 p.m.
The point is, `next` is always called twice. Only we see it differently if it's called twice on the same iterable, than on two different iterables. .-)

perimeter on Dec. 20, 2021, 9:25 p.m.
How does this work for the case of an even first iterable ( e.g. 'abcd', len() is even) which gets chained by another uneven iterable (e.g. '_', len() is uneven)? On the very last iteration, the first next() will yield '_', but the next next() shall raise StopIteration, so the very last "incomplete" pair gets discarded (it makes no sense to add a string '_' and an exception StopIteration), and so map() stops. <a href="https://docs.python.org/3.8/library/functions.html#map">itertools.map</a> <blockquote> If additional iterable arguments are passed, function must take that many arguments and is applied to the items from all iterables in parallel. With multiple iterables, the iterator stops when the shortest iterable is exhausted. </blockquote> So from the last sentence I smell use of zip() internally in map's implementation. Since a single iterator is being referenced here. zip() could aggregate N iterables into a single iterator which produces N-tuples, which in turn are being fed into the passed function. Once one of N iterables is exhausted, zip() stops producing N-tuples too.

veky on Dec. 21, 2021, 5:48 a.m.
What's "this" in your "how does this work"? Though I assume your comment is just a rhetorical question, I'll still give a few details that might not be known. <ul> <li>"it makes no sense to add a string ‘’ and an exception StopIteration", and even if it did, that's not what the code would do. Python strongly distinguishes _returning an object and raising it. First, raising can be done only if it is an exception. Second, when it's done, it flies over any calling function (such as add, map, and even splitpairs) until it finds something that handles it (eventually, the REPL itself). So, add would never get its fingers on StopIteration _if it were raised anyway. [It can also be used as any object without raising, see e.g. line 39 <a href="https://py.checkio.org/mission/haunted-house/publications/veky/python-3/4d/share/536641e847313a70459561e020511d6c/">here</a> and <a href="https://py.checkio.org/mission/haunted-house/publications/veky/python-3/4d/share/536641e847313a70459561e020511d6c/#comment-49495">this thread</a>.</li> <li>"and so map() stops", yes, considering that exceptions naturally bubble through called functions, it seems obvious. However, PEP472 has complicated the life a bit, though of course map retained the same functionality.</li> <li>"I smell use of zip() internally in map’s implementation" - LOL. In fact, history was reverse: map was first, long before zip. In fact, map even had a feature where you passed None as the first argument, and it would work approximately like zip_longest. zip was introduced precisely as a more readable and useful way of writing map(None, *iterables). See <a href="https://www.python.org/dev/peps/pep-0201/">https://www.python.org/dev/peps/pep-0201/</a>#lockstep-for-loops</li> </ul>

LintuStorm_a8334ed4883e45b9980 on Nov. 25, 2020, 5:39 p.m.
Nice solution with import of two libraries and mapping=)

veky on Nov. 25, 2020, 6:24 p.m.
Ah, but those are only two libraries. How about <a href="https://py.checkio.org/mission/bigger-price/publications/veky/python-3/connecting-the-dots/share/372d435c274057606fea09e86bd13ce7/">three</a>? There's also one solution with four, but you'll have to search for it yourself. ;-)

Uasja_Ljutyj on April 5, 2021, 1:47 p.m.
itertools.chain instead of "+=" ? why?

veky on April 5, 2021, 6:52 p.m.
Why not? :-) More precisely, why would I copy the whole string just to add one character at the end?

_Chico__5d82cee4f5234e78a5c65e on May 12, 2021, 11:57 a.m.
WoW, I learned so much from this solution(altough it is short ;))Great!

veky on May 13, 2021, 12:17 a.m.
Both of those are intentional. ;-]

pokryshkin on June 13, 2021, 7:05 a.m.
imho for Elementary it's rather Creative than Clear

veky on June 13, 2021, 11:18 a.m.
If I invented it, yes. But it is a relatively standard technique. See e.g. `grouper` at <a href="https://docs.python.org/3/library/itertools.html">https://docs.python.org/3/library/itertools.html</a>#itertools-recipes.

amvasiliev80 on Nov. 12, 2021, 4:25 p.m.
Something really usefull to know 123456789012345678901234567890

veky on Nov. 13, 2021, 9:28 p.m.
What are those numbers for?

amvasiliev80 on Nov. 13, 2021, 9:55 p.m.
Just to count the length of first phrase to solve a quest)

perimeter on Dec. 20, 2021, 9:51 p.m.
Great! A great example of map's use with more than one iterable.

4biz18 on July 9, 2022, 7:50 a.m.
Had to read and do some thinking to understand this solution. Also interesting info in the comments. Thnak you!

U.V on Aug. 30, 2022, 1:44 p.m.
This generator is fine, and i will try to use it somewhere!

Ash72 on May 10, 2023, 12:40 p.m.
I used to use zip_longest in such tasks, but now I saw best pythonic way to do it!

veky on May 11, 2023, 3:13 a.m.
Well, this is just one way. But yes, it can be handy to know about it.

Pavellver on May 16, 2023, 8:31 a.m.
Your solution is very easy to understand and short! Great work!

veky on May 16, 2023, 9:39 a.m.
Short, sure. Easy to understand, depends on who's reading it. :-) Thanks.

ainem on June 9, 2023, 4:38 a.m.
I wrote a solution based on this code as a reference. It was a great learning experience, thank you very much. <a href="https://py.checkio.org/mission/split-pairs/publications/ainem/python-3/i-learnd-mapfunc-iterable-iterable-from-vekys-solution/">https://py.checkio.org/mission/split-pairs/publications/ainem/python-3/i-learnd-mapfunc-iterable-iterable-from-vekys-solution/</a>

flowerinapot on June 14, 2023, 5:41 p.m.
Very interesting solution, learned a lot for myself. Thank you very much for explaining everything in the comments

mildm on Jan. 24, 2024, 8:13 p.m.
That's interesting use of iterator but still looks like cheating.

veky on Jan. 26, 2024, 4:22 a.m.
Can you specify more precisely why it looks like cheating to you? <ol> <li>just because it's too short?</li> <li>because map can take more than 2 arguments?</li> <li>because of reusing the same iterator in 2 places?</li> <li>something else?</li> </ol>

mildm on Jan. 26, 2024, 7:43 a.m.
3rd one. It "feels" like parameters of map are independent so can be evaluated in any order or even at same time

veky on Jan. 26, 2024, 7:15 p.m.
Ah yes, that's the intuition from C, which is so obsessed with performance that it doesn't even prescribe the order of evaluation of function arguments. However, in Python, it is fixed to strict left-to-right. Of course, here it does not matter for the (second and third) arguments of `map` (they are in fact the same object, given by just its name, so it really doesn't matter what order they are evaluated in), but for the arguments of `operator.add`. If you have `it = iter('Veky')`, then `next(it) + next(it)` will be `'Ve'`, right? It cannot be `'eV'`, nor `'Vk'`, nor anything else. And after that, the same expression will have the value `'ky'`, again completely deterministically. The documentation for `map` says: "function ~...~ is applied to the items from all iterables in parallel" Its arguments are given by `next(it)` every time, and `add`ed in strictly defined order.

StefanPochmann on March 31, 2024, 3:15 p.m.
Are you saying it's documented that `map` gets the elements from the irritable in left-to-right fashion? I don't see that.

veky on March 31, 2024, 3:27 p.m.
I guess the irritable spelling is intentional. :-D But seriously, how could it be different? "function is applied" to me means the same thing as if the function call was written explicitly, as `add(next(it), next(it))`. In both cases, first next(it) is evaluated before second one.

StefanPochmann on March 31, 2024, 3:45 p.m.
Well `add(next(it), next(it))` is Python code and for that, I know the order is documented. I'm sure I've relied on that order myself quite a few times, and I highly doubt they'd ever change that. Then again, just today I found out they've deprecated `~` on bools, which I also didn't expect and which <a href="https://github.com/python/cpython/pull/103487#issuecomment-2028749940">makes me unhappy</a>.

veky on March 31, 2024, 6:41 p.m.
I think that if you believe that (your first) sentence, and you believe the documentation line I quoted above (function is applied to...), and that it really means "in same order as the order of iterables" (e.g. `map(sub, [3], [5])` cannot yield 2:), then it follows that this behavior is fixed. Yes, deprecating ~ on bools is unfortunate (and I should probably apologize to you since you probably saw ~-indexing from me:), but it is not of the same kind. They wanted to remove bug opportunities that they saw in the wild, by warning on weirdly specified behavior. (and besides, slicing was <a href="https://python-history.blogspot.com/2013/10/why-python-uses-0-based-indexing.html?showComment=1382693285556#c8358877314330219275">already broken</a>) This would simply introduce new bug opportunities, even in standard library code (see `itertools.batched` for example, and note that `zip` was introduced as simply a more readable alternative to `partial(map, None)`)--similar to making exhausted iterators false:-). If we really had a time machine, `True` should have been `-1`, as it was on BASICs of old. Then indexing 2-element list by a bool would work the same, and ~ would actually map to not on bool, the same as & maps to and, and | to or.

StefanPochmann on April 4, 2024, 7:35 a.m.
No, I still don't see any guarantee or even any talk at all about the order in which `map` gets the elements from the iterables. Unlike for <a href="https://docs.python.org/3/library/functions.html#zip">`zip`</a>, which says "The left-to-right evaluation order of the iterables is guaranteed. This makes possible an idiom for clustering a data series into n-length groups using `zip([iter(s)]n, strict=True)`". Yes, quite possibly I got ~-indexing from you. I don't remember :-). At least for ints it'll still work. Tim claims the `~mybool` thing is a "common pitfall" and that there are "numerous examples", but I don't remember ever seeing one, not even in that issue. And I see mistakes all the time, some frequent ones on an almost daily basis. What do you mean about `itertools.batched`? I don't see what it has to do with this.

veky on April 4, 2024, 12:19 p.m.
Well, the whole of my argument (including `batched`) relied on `zip` being just a nicer way of writing map(None, ...). That is, (strict) zip is a specialization of map. However, I see now that in docs for Python 2.5, it says: <blockquote> When there are multiple arguments which are all of the same length, zip() is similar to map() with an initial argument of None. </blockquote> without any mention of differences regarding order, while in Python 2.6 docs, the sentence you refer to <blockquote> The left-to-right evaluation order of the iterables is guaranteed. </blockquote> is added (though, of course, as you note, the evaluation order could potentially be different from extraction order), and in 3.0 docs, the sentence about similarity to map is finally removed. I still think they would be crazy to break this implicit promise--however, I also thought that regarding many more explicit promises, and then PEP 479 happened. :-((

StefanPochmann on April 5, 2024, 9:36 p.m.
I think "evaluation order" there does mean extraction order. Otherwise that whole paragraph (which I only partially quoted) doesn't make sense.

veky on April 5, 2024, 9:42 p.m.
Well, sure, but in various other places, it is specified that the evaluation order of arguments of any function call is always left to right. So if they are the same (generally), then that paragraph makes sense, but it is redundant. :D

StefanPochmann on April 5, 2024, 10:02 p.m.
What various other places? I can only think of the <a href="https://docs.python.org/3/reference/expressions.html#calls">Calls</a> section and the <a href="https://docs.python.org/3/reference/expressions.html#evaluation-order">Evaluation order</a> section about Python expressions. And when `map` calls the given function, that's not a Python expression, so that doc doesn't apply.

veky on April 6, 2024, 6:32 a.m.
I just meant many places on the Internet where Python basics are introduced. Yes, I know about that argument. I just meant that if extraction order of arguments is the same as evaluation order, then since they are the arguments of Python call to map, they should be extracted in the same order in which they are given.

Magu on Sept. 28, 2024, 6:36 p.m.
i learned a lot from this solution. beautiful one. :)

veky on Sept. 28, 2024, 6:37 p.m.
Thanks!

List, list and list again

0 %

PyCharm The Python IDE for Professional Developers. Enjoy productive Python, web and scientific development with PyCharm. Download it now!