Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Extracting elements over multiple lists?

Reply
Thread Tools

Extracting elements over multiple lists?

 
 
Prasad, Ramit
Guest
Posts: n/a
 
      11-15-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.
 
Reply With Quote
 
 
 
 
Dave Angel
Guest
Posts: n/a
 
      11-15-2011
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

 
Reply With Quote
 
 
 
 
Chris Angelico
Guest
Posts: n/a
 
      11-15-2011
On Wed, Nov 16, 2011 at 5:17 AM, Dave Angel <(E-Mail Removed)> 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
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      11-15-2011
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
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      11-15-2011
On Wed, 16 Nov 2011 06:53:26 +1100, Chris Angelico wrote:

> On Wed, Nov 16, 2011 at 5:17 AM, Dave Angel <(E-Mail Removed)> 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
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      11-15-2011
On Wed, Nov 16, 2011 at 9:25 AM, Steven D'Aprano
<(E-Mail Removed)> 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
 
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
number of distinct elements in a const container and iterating over the distinct elements Hicham Mouline C++ 1 04-11-2010 10:56 AM
VOIP over VPN over TCP over WAP over 3G Theo Markettos UK VOIP 2 02-14-2008 03:27 PM
newb: recurse over elements children and disable all form elements SteveKlett@gmail.com Javascript 4 09-20-2006 07:42 AM
extracting link from elements content smarto59@hotmail.com XML 0 02-12-2005 11:32 AM
Rubish Way of extracting elements Daniel V÷lkerts Ruby 12 08-18-2004 03:24 PM



Advertisments