Extracting elements over multiple lists?

[JoeM]

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?

 

[John Gordon]

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)

 

[Laurent Claessens]

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

 

[JoeM]

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

 

[John Gordon]

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.)

 

[Peter Otten]

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
throwaway list of None-s. You are adding cruft to your code.

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.

 

[Jean-Michel Pichavant]

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

 

[Dave Angel]

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.

 

[Terry Reedy]

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.

 

[Laurent Claessens]

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

 

[Prasad, Ramit]

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.

 

[Dave Angel]

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.

 

[Chris Angelico]

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

 

[Steven D'Aprano]

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 D'Aprano]

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`.

 

[Chris Angelico]

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.

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