Use cases for del

[Ron Adam]

Grant Edwards wrote:

> On 2005-07-07, Ron Adam <rrr at ronadam.com> wrote:
> 
>>Grant Edwards wrote:
>>
>>
>>>On 2005-07-06, Ron Adam <rrr at ronadam.com> wrote:
>>>
>>>
>>>
>>>>It would be a way to set an argument as being optional without
>>>>actually assigning a value to it.  The conflict would be if
>>>>there where a global with the name baz as well.  Probably it
>>>>would be better to use a valid null value for what ever baz if
>>>>for.  If it's a string then "", if its a number then 0, if it's
>>>>a list then [], etc...
>>>
>>>Except those aren't "null values" for those types.  0 is a
>>>perfectly good integer value, and I use it quite often. There's
>>>a big difference between an "invalid integer value" and an
>>>integer with value 0.
>>
>>Why would you want to use None as an integer value?
> 
> 
> 1) So I know whether an parameter was passed in or not. Perhaps
>    it's not considered good Pythonic style, but I like to use a
>    single method for both get and set operations.  With no
>    parameters, it's a get.  With a parameter, it's a set:
> 
>    class demo:
>       def foo(v=None):
>           if v is not None:
>               self.v = v
>           return self.v   

You are really checking if v exists, so having it undefined in namespace 
  as the default is consistent with what you are doing.

As I said above...

 >>>>It would be a way to set an argument as being optional without
 >>>>actually assigning a value to it.

So it would still work like you expect even though v is not bound to 
anything.  Like I said the bigger problem is that globals will be 
visible and that would create a conflict.  Setting a value to None in a 
function hides globals of the same name.  That wouldn't happen if None 
unbound names as del does.

So you would need to use something else for that purpose I suppose, but 
that was why None became a literal in the first place, so maybe it's 
taking a step backwards.


> 2) So I can use it as sort of a NaN equivalent.
> 
>    if self.fd is None:
>       self.fd = os.open('foo.bar','w')
>    
>    if self.fd is not None:
>       os.close(self.fd)
>       self.fd = None      

It would still work as you expect.  A while back I suggested an 'also' 
for if that would do exactly that with only one test.  Nobody liked it.

      if self.fd is None:
         self.fd = os.open('foo.bar','w')
         # do something with self.fd

      also:
         os.close(self.fd)
         self.fd = None


>>If a value isn't established yet, then do you need the name
>>defined?
>  
> I find it more obvious to set the name to None during the
> periods that it isn't valid than to delete it and check for a
> NameError when I want to know if the value is usable or not.

You would still be able to do that explicitly and it probably would be a 
good idea when you aren't sure if a name is left over from something else.

If a name is None, it means it's available and unassigned, so you don't 
have to check for a NameError.


>>Wouldn't it be better to wait until you need the name then
>>give it a value?
> 
> "Better" is a value judgement.  I prefer setting it None and
> than deleting it and then checking for existance.

They would be the same in this case.  Setting it to None would delete it 
also.  And checking it for None will let you know it's available or if 
it has a value...

You are right that it's a value judgment.  I agree.  BTW, I'm sort of 
just exploring this a bit, not trying to argue it's any better than what 
we currently do.  I think it could work either way, but it would mean 
doing things in a different way also, not neccisarily a good idea.

Cheers,
Ron