From: Alex Martelli [mailto:aleax@aleax.it]
>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++).
Rats, you're right. I can never get the C++ terminology correct...
>> 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).
Oh, I agree. Sorry, that was just an offhand comment without enough detail
to make sense on its own. In a way, I was expressing mild support for the
PEP as a general solution to "issues like this".
>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:-).
Yes. I was taking as a given that if the original question had been asked,
then there was at least a perceived need. And refining that need into a
protocol is David's problem (should he want to go down that route). Of
course, David has since clarified his original question - what he's really
concerned about is telling whether calling next() on an iterator destroys
information (as it does for a file iterator). That's a valid concern, but as
I pointed out it's a property of the container, not of the iterator [and
querying the container as to whether its iterators *have* that property is
back to where we started].
I think a key issue here is that Python iterators are real objects, not
"concepts" as they are in C++. But my brain isn't up to understanding *why*
that issue is key...:-)
[I knew I shouldn't have started this].
>> chance, by requiring that the container support a richer
>> interface, or just by type testing.
>
>*Shudder*. You're advocating MORE type-testing...?
Definitely not. I was trying to point out that there may be a hole, if type
testing *is* the only answer. But the hole could easily be in my ability to
think of a better solution (quite possible, as I don't have the problem
myself).
Paul.
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