# Extracting elements over multiple lists?

Discussion in 'Python' started by JoeM, Nov 7, 2011.

1. ### JoeMGuest

Howdy,

If I have a few lists like

a=[1,2,3,4,5]
b=["one", "two", "three", "four", "five"]
c=["cat", "dog", "parrot", "clam", "ferret"]

what is the most pythonic method of removing the first element from
all of the lists?

A list comprehension such as [arr[1:] for arr in a,b,c]
gives a single 2d list, which is not what I'm shooting for. Any
suggestions?

JoeM, Nov 7, 2011

2. ### John GordonGuest

In <> JoeM <> writes:

> a=[1,2,3,4,5]
> b=["one", "two", "three", "four", "five"]
> c=["cat", "dog", "parrot", "clam", "ferret"]

> what is the most pythonic method of removing the first element from
> all of the lists?

for arr in [a,b,c]:
arr.pop(0)

--
John Gordon A is for Amy, who fell down the stairs
B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

John Gordon, Nov 7, 2011

3. ### Laurent ClaessensGuest

Le 07/11/2011 18:12, JoeM a écrit :
> Howdy,
>
> If I have a few lists like
>
> a=[1,2,3,4,5]
> b=["one", "two", "three", "four", "five"]
> c=["cat", "dog", "parrot", "clam", "ferret"]
>
> what is the most pythonic method of removing the first element from
> all of the lists?

Do you want to remove the first item of each list, or to create new
lists that contain the same as a,b,c but with one element less ?

Something like what you wrote :
[arr[1:] for arr in a,b,c]
will create *new* lists.

Assuming you don't want new lists, I would do :

a=[1,2,3,4,5]
b=["one", "two", "three", "four", "five"]
c=["cat", "dog", "parrot", "clam", "ferret"]

for x in [a,b,c]:
x.remove(x[0])

print a
print b
print c

I think that writing
>>> [x.remove(x[0]) for x in [a,b,c]]

instead of the for loop is cheating ... but it also does the job.

Have a good after noon
Laurent

Laurent Claessens, Nov 7, 2011
4. ### JoeMGuest

Thanks guys, I was just looking for a one line solution instead of a
for loop if possible. Why do you consider

[x.remove(x[0]) for x in [a,b,c]]

cheating? It seems compact and elegant enough for me.

Cheers

JoeM, Nov 7, 2011
5. ### John GordonGuest

In <> JoeM <> writes:

> Thanks guys, I was just looking for a one line solution instead of a
> for loop if possible. Why do you consider

> [x.remove(x[0]) for x in [a,b,c]]

> cheating? It seems compact and elegant enough for me.

I wouldn't call it cheating, but that solution does a fair bit of
unneccessary work (creating a list comprehension that is never used.)

--
John Gordon A is for Amy, who fell down the stairs
B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

John Gordon, Nov 7, 2011
6. ### Peter OttenGuest

JoeM wrote:

> Thanks guys, I was just looking for a one line solution instead of a
> for loop if possible. Why do you consider
>
> [x.remove(x[0]) for x in [a,b,c]]
>
> cheating? It seems compact and elegant enough for me.

I think it's a misconception that you are avoiding the for-loop. You move it
into [...] and declare it more elegant, but in reality you are creating a

That is not only superfluous, but also misleading. A simple for-loop like

for x in a, b, c:
del x[0]

on the other hand makes your intention crystal-clear.

Peter Otten, Nov 7, 2011
7. ### Jean-Michel PichavantGuest

JoeM wrote:
> Thanks guys, I was just looking for a one line solution instead of a
> for loop if possible. Why do you consider
>
> [x.remove(x[0]) for x in [a,b,c]]
>
> cheating? It seems compact and elegant enough for me.
>
>
>
> Cheers
>

This is a one liner, but since you asked something *pythonic*, John's
solution is the best imo:

for arr in [a,b,c]:
arr.pop(0)

(Peter's "del" solution is quite close, but I find the 'del' statement
tricky in python and will mislead many python newcomers)

JM

Jean-Michel Pichavant, Nov 7, 2011
8. ### Dave AngelGuest

On 11/07/2011 01:01 PM, JoeM wrote:
> Thanks guys, I was just looking for a one line solution instead of a
> for loop if possible. Why do you consider
>
> [x.remove(x[0]) for x in [a,b,c]]
>
> cheating? It seems compact and elegant enough for me.
>
>
>
> Cheers

Are you considering the possibility that two of these names might
reference the same list?

a = [42, 44, 6, 19, 48]
b = a
c = b

for x in [a,b,c]:
x.remove(x[0])

now a will have [19,48] as its content.

--

DaveA

Dave Angel, Nov 7, 2011
9. ### Terry ReedyGuest

On 11/7/2011 1:22 PM, John Gordon wrote:
> In<> JoeM<> writes:
>
>> Thanks guys, I was just looking for a one line solution instead of a
>> for loop if possible. Why do you consider

>
>> [x.remove(x[0]) for x in [a,b,c]]

>
>> cheating? It seems compact and elegant enough for me.

It looks like incomplete code with 'somelists = ' or other context
omitted. It saves no keypresses '[',...,SPACE,...,']' versus
....,':',ENTER,TAB,... . (TAB with a decent Python aware editor.)

> I wouldn't call it cheating, but that solution does a fair bit of
> unneccessary work (creating a list comprehension that is never used.)

The comprehension ( the code) is used, but the result is not. If the
source iterator has a large number of items rather than 3, the throwaway
list could become an issue. Example.

fin = open('source.txt')
fout= open('dest.txt, 'w')
for line in fin:
fout.write(line.strip())
# versus
[fout.write(line.strip()) for line in fin]

If source.txt has 100 millions lines, the 'clever' code looks less
clever ;=). Comprehensions are intended for creating collections (that
one actually wants) and for normal Python coding are best used for that.

--
Terry Jan Reedy

Terry Reedy, Nov 8, 2011
10. ### Laurent ClaessensGuest

Le 07/11/2011 19:01, JoeM a écrit :
> Thanks guys, I was just looking for a one line solution instead of a
> for loop if possible. Why do you consider
>
> [x.remove(x[0]) for x in [a,b,c]]
>
> cheating? It seems compact and elegant enough for me.

I have the feeling that it does not do what I expect it does just by
seeing the line. It is list comprehension, but the point is absolutely
not in creating a list.

I'd say it breaks the rule «Explicit is better than implicit.» while
«Special cases aren't special enough to break the rules.»

But well... could be a matter of taste; I prefer the loop.

Laurent

Laurent Claessens, Nov 8, 2011

>>for x in a, b, c:

>> del x[0]

>for arr in [a,b,c]:
> arr.pop(0)

>(Peter's "del" solution is quite close, but I find the 'del' statement
>tricky in python and will mislead many python newcomers)

Can you expand on why 'del' is "tricky"/misleading?

Ramit

Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423

--

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legalentity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.

12. ### Dave AngelGuest

On 11/15/2011 12:01 PM, Prasad, Ramit wrote:
> <SNIP>
>> (Peter's "del" solution is quite close, but I find the 'del' statement
>> tricky in python and will mislead many python newcomers)

> Can you expand on why 'del' is "tricky"/misleading?
>
> Ramit
>

a = someexpression...
b = a
.....
del a

Does not (necessarily) delete the object that a refers to. It merely
deletes the symbol a.

--

DaveA

Dave Angel, Nov 15, 2011
13. ### Chris AngelicoGuest

On Wed, Nov 16, 2011 at 5:17 AM, Dave Angel <> wrote:
> a = someexpression...
> b = a
> ....
> del a
>
> Does not (necessarily) delete the object that a refers to.  It merely
> deletes the symbol a.

I'd have to classify that as part of the change of thinking necessary
for a refcounted language, and not specific to del at all. The del
statement is identical to "a = None" in terms of deleting objects;
someone who's come from C++ might want to explicitly del every
variable before returning, but that's the only way that it's tied to
'del'.

ChrisA

Chris Angelico, Nov 15, 2011
14. ### Steven D'ApranoGuest

On Tue, 15 Nov 2011 17:01:23 +0000, Prasad, Ramit wrote:

> Can you expand on why 'del' is "tricky"/misleading?

People often imagine that the del statement sends a message to the object
"please delete yourself", which then calls the __del__ method. That is
incorrect.

"del x" is an unbinding operation, it removes the *name* "x" from the
current namespace. As a side-effect, if the object which was bound to x
no longer has any other references to it, then the garbage collector will
delete it and __del__ may be called.

(I say "may be called" rather than "will" because there are circumstances
where __del__ methods won't get called, such as during interpreter
shutdown.)

On the other hand, "del x" does work like the way people expect. It
deletes items from collections (lists, dicts, etc.) and does so by
calling the method x.__delitem__(i). This also may cause the garbage
collector to delete the object which was at x if that was the last
reference to that object.

CPython's implementation keeps a count of references for each object, and
the garbage collector deletes the object immediately that reference count
reaches zero. This is fast, simple, deterministic (objects will be
predictably deleted as soon as they can be), but simple-minded, and so it
is aided by a second garbage collector which runs periodically, looking
for reference cycles. You can set how often this second garbage collector
runs using the gc module.

Jython uses the Java garbage collector, and IronPython the .Net garbage
collector. Neither are reference counters, and (as far as I know) neither
guarantees that objects will be deleted as soon as they are free to be
deleted. They will be deleted whenever the garbage collector gets around
to it.

--
Steven

Steven D'Aprano, Nov 15, 2011
15. ### Steven D'ApranoGuest

On Wed, 16 Nov 2011 06:53:26 +1100, Chris Angelico wrote:

> On Wed, Nov 16, 2011 at 5:17 AM, Dave Angel <> wrote:
>> a = someexpression...
>> b = a
>> ....
>> del a
>>
>> Does not (necessarily) delete the object that a refers to. Â It merely
>> deletes the symbol a.

>
> I'd have to classify that as part of the change of thinking necessary
> for a refcounted language, and not specific to del at all.

Languages aren't refcounted. Or at least, *Python* isn't a refcounted
language. CPython is a refcounted implementation. IronPython and Jython
are not. del behaves exactly the same in IronPython and Jython as it does
in CPython: it removes the name, which may have a side-effect of deleting
the object.

> The del
> statement is identical to "a = None" in terms of deleting objects;

I'm not entirely sure what you arr trying to say here. I *think* you are
trying to say is this:

Given that `a` is bound to my_object initially, `del a`
from the point of view of my_object is no different
from re-binding a to some other object such as None
(or any other object).

which is true as far as it goes, but it fails to note that the name "a"
no longer exists after `del a` while it does exist after `a = None`.

--
Steven

Steven D'Aprano, Nov 15, 2011
16. ### Chris AngelicoGuest

On Wed, Nov 16, 2011 at 9:25 AM, Steven D'Aprano
<> wrote:
> Languages aren't refcounted. Or at least, *Python* isn't a refcounted
> language. CPython is a refcounted implementation. IronPython and Jython
> are not. del behaves exactly the same in IronPython and Jython as it does
> in CPython: it removes the name, which may have a side-effect of deleting
> the object.

Yes, I was sloppy there. A non-manually-memory-managed language, if
you will; it's part of Python's spec that you do NOT have to
explicitly release objects you're no longer using.

>> The del
>> statement is identical to "a = None" in terms of deleting objects;

>
> I'm not entirely sure what you arr trying to say here. I *think* you are
> trying to say is this:
>
>    Given that `a` is bound to my_object initially, `del a`
>    from the point of view of my_object is no different
>    from re-binding a to some other object such as None
>    (or any other object).
>
> which is true as far as it goes, but it fails to note that the name "a"
> no longer exists after `del a` while it does exist after `a = None`.

Right. Both actions have the same effect wrt deleting my_object; the
only connection between Python's "del" and C++'s "delete" is that,
which del shares with "a = None".

The fact is that, regardless of the Python implementation, deleting
*objects* is not the programmer's responsibility. The only thing he
can or must do is delete *names*.

del a
del globals()['a']
globals().__delitem__('a')

are all roughly equivalent (assuming that a is global). Maybe this is
the best way to explain it - that you're deleting from a "dictionary"
(which may or may not actually be implemented as a dict) of local
names.

ChrisA

Chris Angelico, Nov 15, 2011