Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Pre-PEP: reverse iteration methods

Reply
Thread Tools

Pre-PEP: reverse iteration methods

 
 
Lulu of the Lotus-Eaters
Guest
Posts: n/a
 
      09-25-2003
|> >As infinite iterators are rare, it would not be too cumbersome to
|> >let them identify themselves as such.

David Eppstein <(E-Mail Removed)> wrote previously:
|It would be quite cumbersome to have to identify simple generators as
|infinite or finite manually, and impossible (halting problem) to do so
|reliably automatically.

Humans cannot solve the halting problem either, FWIW. Just because a
programmer THINKS an iterator is finite, it don't mean it is!

Actually, to my mind, infinite iterators are the RULE not the exception.
Or if not actually infinite, iterators tend to be *indefinitely* large.
That is, I use an iterator because I want to deal with something at
runtime whose size is unbounded at programming time (e.g. an external
file, or data from a socket).

Overall, this makes me -1 on the whole idea of reverse iteration.

Moreover, even iterators that are known to be finite and even of
reasonable size will often be SLOW. For example, I might naturally
write a simple generator to get data from a socket. Each time a block
of data comes in, I take some action based on it. I want those actions
to happen as soon as the relevant chunk of data is available, even
though the socket is probably much slower than the CPU. If my GUI needs
to wait for ALL the data in order to play the event in reverse, that
might cause very uncomfortable pauses in the interface. On the other
hand, if the widget updates every second (even for a couple minutes
total), that seems reasonable enough.

Yours, Lulu...

--
_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY: Postmodern Enterprises _/_/_/
_/_/ ~~~~~~~~~~~~~~~~~~~~[(E-Mail Removed)]~~~~~~~~~~~~~~~~~~~~~ _/_/
_/_/ The opinions expressed here must be those of my employer... _/_/
_/_/_/_/_/_/_/_/_/_/ Surely you don't think that *I* believe them! _/_/


 
Reply With Quote
 
 
 
 
David Eppstein
Guest
Posts: n/a
 
      09-25-2003
In article <(E-Mail Removed)>,
Lulu of the Lotus-Eaters <(E-Mail Removed)> wrote:

> David Eppstein <(E-Mail Removed)> wrote previously:
> |It would be quite cumbersome to have to identify simple generators as
> |infinite or finite manually, and impossible (halting problem) to do so
> |reliably automatically.
>
> Humans cannot solve the halting problem either, FWIW. Just because a
> programmer THINKS an iterator is finite, it don't mean it is!


Well, true, but if you are a programmer and don't know whether your
program is always going to halt, you probably shouldn't have written it
that way.

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science
 
Reply With Quote
 
 
 
 
Lulu of the Lotus-Eaters
Guest
Posts: n/a
 
      09-25-2003
|> Humans cannot solve the halting problem either, FWIW. Just because a
|> programmer THINKS an iterator is finite, it don't mean it is!

David Eppstein <(E-Mail Removed)> wrote previously:
|Well, true, but if you are a programmer and don't know whether your
|program is always going to halt, you probably shouldn't have written it
|that way.

Sure, I generally agree. But creating a special __finite__ attribute
(or whatever) introduces a new source of potentially rather bad errors.
Doing a reverse iteration on an iterator that turns out to be infinite
(or even just VERY big) will presumably either freeze the system or
cause a memory overrun.

Moreover, I can see a class of cases where it's not obvious about
halting. A generator that depends on some runtime data might halt for
all the "normal" cases, but wind up running infinitely long for special
(untested) cases. Some attractors, for example, with the right
parameters (or wrong, depending on how you think of it) are strange, if
you know what I mean .

Yours, Lulu...

--
mertz@ | The specter of free information is haunting the `Net! All the
gnosis | powers of IP- and crypto-tyranny have entered into an unholy
..cx | alliance...ideas have nothing to lose but their chains. Unite
| against "intellectual property" and anti-privacy regimes!
-------------------------------------------------------------------------


 
Reply With Quote
 
Andrew Dalke
Guest
Posts: n/a
 
      09-25-2003
Stephen Horne:
> I disagree with this. IMO something that modifies a value in place
> should be named using a verb (such as reverse, or sort, or update...).


You are correct. And I can't even blame it on lack of sleep.

Andrew
http://www.velocityreviews.com/forums/(E-Mail Removed)


 
Reply With Quote
 
Stephen Horne
Guest
Posts: n/a
 
      09-25-2003
On Wed, 24 Sep 2003 09:57:18 GMT, "Raymond Hettinger"
<(E-Mail Removed)> wrote:

>> Second, I'm not quite ready to drop my property idea
>>
>> An advantage is that the object returned by the property can sensibly
>> support more than just iteration - e.g. slicing (as touched on in the
>> PEP284 thread). So for instance...
>>
>> >>> x = range(10)
>> >>> list(x.backward)

>> [9, 8, 7, 6, 5, 4, 3, 2, 1, 0]

>
>I'm not clear on the details of what you're proposing. What is
>type(x.backward)?


Some made-up proxy class that understands that certain operations will
work as if the list was reversed.

For integer lists, I'd use much the same thing but on the
set-of-all-integers object I proposed in the earlier thread. So I
could write...

for i in integers.backwards [:10] :
print i

....to do the same as your...

for i in xrange (10).iter_backwards () :
print i

....though I'm also having this idea about using the 'int' type object
to implement these again. It makes a certain sense for type names to
also act as abstract sets of possible values. For typechecking
purposes, for instance, it might be nice to be able to write...

if x in float :
do stuff with float value

Of course that's a long way from compelling given that we already have
the isinstance function, but what is attracting me is that these two
ideas...

1. Provide objects (or extend the type name objects) to provide
the abstraction of a set of values of that type, implementing
whatever operations are practical and useful for that
abstraction.

2. Provide properties of objects (including that abstract set of
integers) which act as proxies for the object, but providing
an modified view of that object (including a backward view of a
sequence object, but possibly other things too).

....seem to provide, either alone or in combination, natural solutions
to several problems. For instance, you don't just get the ability to
loop through a range of integers backwards...

for i in integers.ibackwards [:50] :

But equally the ability to iterate through a sequence backwards...

for i in x.ibackwards [:50] :

And basically you are doing the same thing in each case - its just
that the first example slices an abstract sequence as opposed to one
that is physically held in memory.

>Please show what a pure python version would look like
>(taking UserList as an example).


I didn't use UserList, but I did post example code in the "Comment on
PEP-0322: Reverse Iteration Methods" thread. I wasn't so keen in that
post, but I seem to like the idea again now.

>> >* Should enumerate() be included? It would only provide reverse iteration
>> > whenever the underlying sequence supported it.

>>
>> Why not...
>>
>> for i, j in enumerate (listname.iter_backwards ()) :
>>
>> in other words, as enumerate can handle the already-reversed
>> sequence/iteration, I don't see the point.

>
>The point is that enumerate will starting numbering from zero
>for the last item:


Yes - I wasn't thinking straight, sorry about that. Just to put a
thought in based on those two ideas above, though, how about...

>>> x=["a", "b", "c"]
>>> print x.enumerated

[(0, "a"), (1, "b"), (2, "c")]
>>> print x.backwards.enumerated

[(0, "c"), (1, "b"), (2, "c")]
>>> print x.enumerated.backwards

[(2, "c"), (1, "b"), (0, "c")]

'enumerated' need not create the list or iterator immediately - again,
it returns a proxy which implements the modified behaviour. Having a
proxy to a proxy gives IMO quite a neat solution.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Struts - Problem with nested iteration or double iteration Rudi Java 5 10-01-2008 03:30 AM
PEP 322: Reverse Iteration (REVISED, please comment) Raymond Hettinger Python 31 11-06-2003 07:27 AM
PEP 322: Reverse Iteration (second revision, please comment) Raymond Hettinger Python 14 11-01-2003 05:51 PM
RE: PEP 322: Reverse Iteration (REVISED, please comment) Robert Brewer Python 1 10-29-2003 07:28 PM
Comment on PEP-0322: Reverse Iteration Methods Raymond Hettinger Python 59 09-29-2003 05:35 PM



Advertisments