| 19:09 | <devsnek> | is there a name for zipping iterators where the iteration goes until specifically the first iterator is empty |
| 19:09 | <devsnek> | instead of the shortest or longest iterator |
| 19:17 | <TabAtkins> | I haven't heard of one, but zip-first is the obvious name from the standard naming scheme |
| 23:15 | <bakkot> | what do you do if the first one is shorter than the second? |
| 23:25 | <TabAtkins> | stop, like a normal zip does |
| 23:26 | <TabAtkins> | (traditionally, zip stops at the length of the shortest input) |
| 23:26 | <bakkot> | *longer, rather |
| 23:27 | <TabAtkins> | if you meant the opposite case, where the first is longer than the second, then you need a default value for the additional iterators, just like zip-longest usually does https://docs.python.org/3/library/itertools.html#itertools.zip_longest |
| 23:27 | <bakkot> | fascinating |
| 23:27 | <bakkot> | never seen that function before |
| 23:27 | <TabAtkins> | I get that response most of the time i pull out the itertools manual page |
| 23:27 | <bakkot> | I always written zip(first, chain(second, repeat(default))) or equivalents |
| 23:28 | <bakkot> | on reflection, I'm going to keep writing that, since it's composed of primitives people will have seen before instead of being a new thing |
| 23:28 | <TabAtkins> | nothing wrong with that, tho it depends on knowing which one will end first (which you probably do usually know) |
| 23:28 | <bakkot> | sure is a lot of stuff in itertools |
| 23:29 | <TabAtkins> | well, wait, no it doesn't - the second iterator is now infinite, so it'll always consume all of first and then stop. never mind. |
| 23:29 | <bakkot> | wait, hang on, does zip_longest not allow you to specify different values for the first and second? |
| 23:29 | <bakkot> | that seems like it would rarely be useful |
| 23:29 | <bakkot> | I feel like most of my zipping is of unlike types |
| 23:30 | <TabAtkins> | correct, it doesn't. gotta chain if they're unlike types |
| 23:30 | <bakkot> | huh |