Iterator current/prev value

Marcus Stade marcus at
Sun Mar 23 11:22:20 PDT 2014

Could the iterator protocol be extended to also have a `current` or `prev`
property, which contains the result of the previous call to `next`? If
`next` has never been called, presumably this property would return

I've searched the archives for this question, and the only semi-satisfying
answer I've found is this[1]:

Rehashed Java (hasMore/getNext) and C# (Current/MoveNext) protocols
> involving two methods, which costs more for implementors (groups 2 and 3,
> however ordered) and adds incoherence hazard (two methods get out of sync;
> C# tries to mitigate common mistake with Java's, but still has dual
> out-of-sync hazard to Java's).
> MM agreed with BE that Python's is simplest given other constraints we
> can't change, or "least bad".

My apologies if I'm beating a dead horse here, or my ignorance is keeping
me from fully grasping the nuances of these discussions and decisions that
have followed. Unless I've missed something – which is very likely –
shouldn't the implementation cost for developers be virtually zero since it
could/would/should be done by the very same mechanism that generators the
iterator object in the first place? That is, the implementation cost is in
the engine, not user land.

I can sort of understand the sync argument given that results include the
`done` property, but couldn't the same be said for any result of calling
`next` then? I.e. as soon as an iterator yields a result, the `done`
property is effectively out of date and the only way to truly know whether
you'll get another value is to call `next` and hope for the best? In any
case, the return value of a `current` or `prev` property could be an object
with the single property `value`; ensuring there's nothing that can be out
of sync.

This is assuming that the `current` or `prev` property is indeed
implemented by the engine and not user land, as that indeed both carries
implementation cost and the risk out running out of sync. Is there any way
other than generator functions to implement iterators? Are any ol' object
with a function called `next` an iterator?

I'm probably just confused about the whole thing, and would very much
appreciate to be set straight.

-- Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list