[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-list
Subject:    Re: Use cases for del
From:       Ron Adam <rrr () ronadam ! com>
Date:       2005-07-06 16:10:16
Message-ID: InTye.185656$IO.42677 () tornado ! tampabay ! rr ! com
[Download RAW message or body]

Steven D'Aprano wrote:
> On Wed, 06 Jul 2005 10:00:02 -0400, Jp Calderone wrote:
> 
> 
> > On Wed, 06 Jul 2005 09:45:56 -0400, Peter Hansen <peter@engcorp.com> wrote:
> > 
> > > Tom Anderson wrote:
> > > 
> > > > How about just getting rid of del? Removal from collections could be
> > > > done with a method call, and i'm not convinced that deleting variables
> > > > is something we really need to be able to do (most other languages
> > > > manage without it).
> > > 
> > > Arguing the case for del: how would I, in doing automated testing,
> > > ensure that I've returned everything to a "clean" starting point in all
> > > cases if I can't delete variables?  Sometimes a global is the simplest
> > > way to do something... how do I delete a global if not with "del"?
> > > 
> > 
> > Unless you are actually relying on the global name not being defined, "someGlobal \
> > = None" would seem to do just fine. 
> > Relying on the global name not being defined seems like an edge case.
> 
> 
> Er, there is a lot of difference between a name not existing and it being
> set to None.

Yes, they are not currently the same thing.


But what if assigning a name to None actually unbound it's name?


And accessing an undefined name returned None instead of a NameError?


Using an undefined name in most places will still generate some sort of 
an None type error.

I think the biggest drawback to this second suggestion is that we would 
have to test for None in places where it would matter, but that's 
probably a good thing and enables checking if a variable exists without 
using a try-except.


$ cat mymodule2.py

# define some temporary names
a, b, c, d, e, f = 1, 2, 3, 4, 5, 6
# do some work
result = a+b+c+d*e**f
# delete the temp variables
a = b = c = d = e = f = None    # possibly unbind names

This would work if None unbound names.


> It is bad enough that from module import * can over-write your variables
> with the modules' variables, but for it to do so with DELETED variables is
> unforgivable.

Yes, I agree using None as an alternative to delete currently is 
unacceptable.

Cheers,
Ron
-- 
http://mail.python.org/mailman/listinfo/python-list


[prev in list] [next in list] [prev in thread] [next in thread]