Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #15421 > unrolled thread

Extracting elements over multiple lists?

Back to article view | Back to comp.lang.python

Contents

  Extracting elements over multiple lists? JoeM <josephmeiring@gmail.com> - 2011-11-07 09:12 -0800
    Re: Extracting elements over multiple lists? John Gordon <gordon@panix.com> - 2011-11-07 17:37 +0000
    Re: Extracting elements over multiple lists? Laurent Claessens <moky.math@gmail.com> - 2011-11-07 18:44 +0100
      Re: Extracting elements over multiple lists? JoeM <josephmeiring@gmail.com> - 2011-11-07 10:01 -0800
        Re: Extracting elements over multiple lists? John Gordon <gordon@panix.com> - 2011-11-07 18:22 +0000
          Re: Extracting elements over multiple lists? Terry Reedy <tjreedy@udel.edu> - 2011-11-07 19:06 -0500
        Re: Extracting elements over multiple lists? Peter Otten <__peter__@web.de> - 2011-11-07 19:33 +0100
        Re: Extracting elements over multiple lists? Jean-Michel Pichavant <jeanmichel@sequans.com> - 2011-11-07 19:51 +0100
        Re: Extracting elements over multiple lists? Dave Angel <d@davea.name> - 2011-11-07 15:06 -0500
        Re: Extracting elements over multiple lists? Laurent Claessens <moky.math@gmail.com> - 2011-11-08 08:07 +0100
        RE: Extracting elements over multiple lists? "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2011-11-15 17:01 +0000
          Re: Extracting elements over multiple lists? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-15 22:21 +0000
        Re: Extracting elements over multiple lists? Dave Angel <d@davea.name> - 2011-11-15 13:17 -0500
        Re: Extracting elements over multiple lists? Chris Angelico <rosuav@gmail.com> - 2011-11-16 06:53 +1100
          Re: Extracting elements over multiple lists? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-15 22:25 +0000
            Re: Extracting elements over multiple lists? Chris Angelico <rosuav@gmail.com> - 2011-11-16 09:54 +1100
      Re: Extracting elements over multiple lists? Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-11-07 19:06 +0100

#15421 — Extracting elements over multiple lists?

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?

[toc] | [next] | [standalone]

#15422

In <b9e53a75-7490-4b6a-844a-20cfce263939@a12g2000vbz.googlegroups.com> JoeM <josephmeiring@gmail.com> 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
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#15424

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

[toc] | [prev] | [next] | [standalone]

#15425

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

[toc] | [prev] | [next] | [standalone]

#15427

In <cf007146-3a08-44c4-bf01-d1a9253c83e3@o19g2000vbk.googlegroups.com> JoeM <josephmeiring@gmail.com> 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
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#15445

On 11/7/2011 1:22 PM, John Gordon wrote:
> In<cf007146-3a08-44c4-bf01-d1a9253c83e3@o19g2000vbk.googlegroups.com>  JoeM<josephmeiring@gmail.com>  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

[toc] | [prev] | [next] | [standalone]

#15428

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

[toc] | [prev] | [next] | [standalone]

#15429

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

[toc] | [prev] | [next] | [standalone]

#15431

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

[toc] | [prev] | [next] | [standalone]

#15460

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

[toc] | [prev] | [next] | [standalone]

#15723

>>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 legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  

[toc] | [prev] | [next] | [standalone]

#15746

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[i]" 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[i] 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

[toc] | [prev] | [next] | [standalone]

#15728

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

[toc] | [prev] | [next] | [standalone]

#15735

On Wed, Nov 16, 2011 at 5:17 AM, Dave Angel <d@davea.name> 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

[toc] | [prev] | [next] | [standalone]

#15748

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

> On Wed, Nov 16, 2011 at 5:17 AM, Dave Angel <d@davea.name> 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

[toc] | [prev] | [next] | [standalone]

#15750

On Wed, Nov 16, 2011 at 9:25 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> 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

[toc] | [prev] | [next] | [standalone]

#15711

Am 07.11.2011 18:44 schrieb Laurent Claessens:
> 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])

Why not

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

?

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web