As for what actually happened in the for loop:
From the Python for statement documentation:
The expression list is evaluated once; it should yield an iterable
object. An iterator is created for the result of the expression_list
.
The suite is then executed once for each item provided by the
iterator, in the order of ascending indices. Each item in turn is
assigned to the target list using the standard rules for assignments,
and then the suite is executed. When the items are exhausted (which is
immediately when the sequence is empty), the suite in the else
clause,
if present, is executed, and the loop
terminates.
I think it is best shown with the aid of an illustration.
Now, suppose you have an iterable object
(such as list
) like this:
out = [a, b, c, d, e, f]
What happen when you do for x in out
is that it creates internal indexer which goes like this (I illustrate it with the symbol ^
):
[a, b, c, d, e, f]
^ <-- here is the indexer
What normally happen is that: as you finish one cycle of your loop, the indexer moves forward like this:
[a, b, c, d, e, f] #cycle 1
^ <-- here is the indexer
[a, b, c, d, e, f] #cycle 2
^ <-- here is the indexer
[a, b, c, d, e, f] #cycle 3
^ <-- here is the indexer
[a, b, c, d, e, f] #cycle 4
^ <-- here is the indexer
[a, b, c, d, e, f] #cycle 5
^ <-- here is the indexer
[a, b, c, d, e, f] #cycle 6
^ <-- here is the indexer
#finish, no element is found anymore!
As you can see, the indexer keeps moving forward till the end of your
list, regardless of what happened to the list!
Thus when you do remove
, this is what happened internally:
[a, b, c, d, e, f] #cycle 1
^ <-- here is the indexer
[b, c, d, e, f] #cycle 1 - a is removed!
^ <-- here is the indexer
[b, c, d, e, f] #cycle 2
^ <-- here is the indexer
[c, d, e, f] #cycle 2 - c is removed
^ <-- here is the indexer
[c, d, e, f] #cycle 3
^ <-- here is the indexer
[c, d, f] #cycle 3 - e is removed
^ <-- here is the indexer
#the for loop ends
Notice that there are only 3 cycles there instead of 6 cycles(!!) (which is the number of the elements in the original list). And that's why you left with half len
of your original len
, because that is the number of cycles it takes to complete the loop when you remove one element from it for each cycle.
If you want to clear the list, simply do:
if (out != []):
out.clear()
Or, alternatively, to remove the element one by one, you need to do it the other way around - from the end to the beginning. Use reversed
:
for x in reversed(out):
out.remove(x)
Now, why would the reversed
work? If the indexer keeps moving forward, wouldn't reversed
also should not work because the number of element is reduced by one per cycle anyway?
No, it is not like that,
Because reversed
method changes the way to the internal indexer
works! What happened when you use reversed
method is to make the
internal indexer moves backward (from the end) instead of
forward.
To illustrate, this is what normally happens:
[a, b, c, d, e, f] #cycle 1
^ <-- here is the indexer
[a, b, c, d, e, f] #cycle 2
^ <-- here is the indexer
[a, b, c, d, e, f] #cycle 3
^ <-- here is the indexer
[a, b, c, d, e, f] #cycle 4
^ <-- here is the indexer
[a, b, c, d, e, f] #cycle 5
^ <-- here is the indexer
[a, b, c, d, e, f] #cycle 6
^ <-- here is the indexer
#finish, no element is found anymore!
And thus when you do one removal per cycle, it doesn't affect how the indexer works:
[a, b, c, d, e, f] #cycle 1
^ <-- here is the indexer
[a, b, c, d, e] #cycle 1 - f is removed
^ <-- here is the indexer
[a, b, c, d, e] #cycle 2
^ <-- here is the indexer
[a, b, c, d] #cycle 2 - e is removed
^ <-- here is the indexer
[a, b, c, d] #cycle 3
^ <-- here is the indexer
[a, b, c] #cycle 3 - d is removed
^ <-- here is the indexer
[a, b, c] #cycle 4
^ <-- here is the indexer
[a, b] #cycle 4 - c is removed
^ <-- here is the indexer
[a, b] #cycle 5
^ <-- here is the indexer
[a] #cycle 5 - b is removed
^ <-- here is the indexer
[a] #cycle 6
^ <-- here is the indexer
[] #cycle 6 - a is removed
^ <-- here is the indexer
Hope the illustration helps you to understand what's going on internally...