On Tuesday 09 July 2002 10:57 am, Moore, Paul wrote:
> IIRC from earlier discussions on the list, iterators "by design" do not
> expose this information. In C++ terms, all Python iterators are forward
> iterators
I think they're _input_ iterators -- you can only "get" items through the
iterator, not "set" them (as you can with forward, but not input,
iterators in C++).
> can introspect a container, to determine what properties its iterators can
> have (but lets not go there - I can see Alex Martelli popping up to claim
> that the adaption PEP will let you do that :-)). But you do have a better
The adaptation (not "adaption") PEP 246 would just obviate the need to
invent yet one more infrastructure/plumbing ad-hoc "solution" here, but
would not by itself alone solve the need to design and designate one or
more protocols for "containers that yield augmented-iterators of kind X"
or for augmented-iterators themselves ("iterator able to replicate itself",
"iterator able to 'rewind'", "iterator to which you can write an item", etc).
The first step in studying such a need is whether it IS in fact a need.
Sure, "rich iterators" might come in handy, but do we NEED them...?
If so, then what kinds of rich-iterators do we in fact need? How to get
at them seems a third-order problem at best (and here, of course, I
would suggest that adaptation IS good for this tertiary problem:-).
> chance, by requiring that the container support a richer interface, or just
> by type testing.
*Shudder*. You're advocating MORE type-testing...?
Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4