Hacker News Reader

Comment by BiteCode_dev | Hacker News Reader

It's a good learning exercise.

Of course, don't use your own hand crafted version in Python, since one is provided with the language and it is better than the one you will likely come up with.

Still, it's interesting because it's simple. So starting from the intro of this article, if you want to go further, try to do the following to match up __builtins__.zip:

- make it lazy (yield would work)

- make it work with any iterable (iter() + StopIteration would work)

- put some type int and a docstring (so that help() gives you informations)

- accept any number of iterables (variadic parameters would work)

- make a second version that accepts a fill value (like itertools.zip_longest)

This will sharpen your python skills, and also will make you appreciate even better how much you get for free with the stdlib (not to mention __builtins__.zip is in C, so it's fast).

View on HN

It's worth noting that `map` is variadic and acts as an nary `zipWith`. I didn't realize that for a while.

    >>> from operator import `add`
    >>> list(map(add, range(5), range(10, 15)))
    [10, 12, 14, 16, 18]
    >>> add3 = lambda x,y,z: x+y+z
    >>> list(map(add3, range(5), range(10, 15), range(100, 105)))
    [110, 113, 116, 119, 122]

> will make you appreciate even better how much you get for free

This is unironically the reason I come back to Python again and again. The language itself is not my favorite: it 'should' be different. But my productivity with it is frankly unmatched.

The "zip" example is an excellent case study. The actual "zip" is by default lazy, it accepts arbitrary iterators, etc. It's the "correct" solution, unlike the one presented in the article, and I have it at my fingertips, in the standard library.

> This is unironically the reason

Can I ask an off topic question? Where did this sudden popular use of “unironically” come from? I don’t get it. Why would it be ironic?

It reminds me of the sudden rise of “literally” a decade or so ago.

"Unironically" here means "seriously", "literally", "actually", etc. It's basically a marker that the speaker is speaking straightly and plainly, without trying to make a joke.

Yes, it's not really antonymous to "ironically" (in the narrower sense of this word) in this context.

I think it's fairly literal, there's a whole brand of humor around pretending to like things that you actually like. "I like C because of all the undefined behavior".

But this is also how word meanings shift over time. Someone will see someone else using that word and not know what it means, but then start using it, etc.

In reality most of these are really simple, the big question is how to handle end of iteration across iterators e.g. given zip(a, b) where a is shorter than b, on the last iteration will b get updated or not?

In Python an iterator is simply an object that implements the __next__ method, and raises StopIteration to signal the end of the iteration.

It's not hard to implement just about any protocol on top of that abstraction, e.g. you have itertools.zip_longest()

I know what an iterator is. I think you missed the point.

Would you like to explain that further?

Progressing an iterator is a side-effect (a mutation).

Depending how the last iteration is handled, zip(a, b) and zip(b, a) with iterators of different sizes can have different behaviours: if a is shorter than b, a naïve implementation would update b in the zip(b, a) case, but not in the zip(a, b) case.

zip is generally implemented as a functional concept, where the iterators take values from the backing iterable structure "by const &". You can implement a custom mutating zip operation on top of the iterator protocol.

I believe masklinn is talking about whether `zip` consumes an extra element from the longer iterator on the last iteration, when the shorter iterator raises StopIteration. And the behavior might vary depending on the order of the arguments.

    def a():
      yield "a1"

    def b():
      yield "b1"
      yield "b2"

    x,y = a(),b()
    zip(x,y) # => [("a1","b1")]
    next(x) # => raise StopIteration
    next(y) # => "b2"

    x,y = a(),b()
    zip(y,x) # => [("b1","a1")]
    next(x) # => raise StopIteration
    next(y) # => raise StopIteration

There is no unique solution to that problem since sometime you want consumption, and sometimes not, for one or more of the parameters.

__builtins__.zip chose to consume iterators in the order they are passed as a parameter, and therefor end up with an assymetric consumption.

That's why itertools.tee exists, so that we can chose case by case.

That reminds me of a lovely paper "How to Add Laziness to a Strict Language Without Even Being Odd" by Wadler and MacQuenn. They use "map" as their running example, but the problem is basically the same.

This is the problem with python's conflation of iterable and iterator, and maybe why so many programmers don't understand the difference when they pick up Java.

> This is the problem with python's conflation of iterable and iterator

It really is not. It’s just a natural outcome of imperative langages. If operations can have side-effects, then combinator behaviour will affect those side-effects.

You could do the same with iterables with side-effecting iterations.

It’s also perfectly logical to be able to iterate an iterator.

Reply on news.ycombinator.com