Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: Use cases for del

Reply
Thread Tools

Re: Use cases for del

 
 
Jp Calderone
Guest
Posts: n/a
 
      07-06-2005
On Wed, 06 Jul 2005 09:45:56 -0400, Peter Hansen <(E-Mail Removed)> 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.

Jp
 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      07-06-2005
On Wed, 06 Jul 2005 10:00:02 -0400, Jp Calderone wrote:

> On Wed, 06 Jul 2005 09:45:56 -0400, Peter Hansen <(E-Mail Removed)> 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.

$ cat mymodule1.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
del a
del b
del c
del d
del e
del f

$ 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 = None
b = None
c = None
d = None
e = None
f = None

Now import them into Python:

py> import mymodule1, mymodule2
py> dir(mymodule1)
['__file__', '__name__', result]
py> dir(mymodule2)
['__file__', '__name__', result, a, b, c, d, e, f]

Or worse, do this:

py> a = 1
py> from mymodule2 import *
py> a + 1
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

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.



--
Steven.

 
Reply With Quote
 
 
 
 
Ron Adam
Guest
Posts: n/a
 
      07-06-2005
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 <(E-Mail Removed)> 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
 
Reply With Quote
 
Stian =?iso-8859-1?Q?S=F8iland?=
Guest
Posts: n/a
 
      07-06-2005
On 2005-07-06 18:10:16, Ron Adam wrote:

> But what if assigning a name to None actually unbound it's name?
> And accessing an undefined name returned None instead of a NameError?


Yes, and we can make

someunknownlist[] = 2

magically do someunknownlist = list() and append 2.


Please.

--
Stian S°iland Work toward win-win situation. Win-lose
Trondheim, Norway is where you win and the other lose.
http://soiland.no/ Lose-lose and lose-win are left as an
exercise to the reader. [Limoncelli/Hogan]
 
Reply With Quote
 
Benji York
Guest
Posts: n/a
 
      07-06-2005
Stian S°iland wrote:
> Yes, and we can make
>
> someunknownlist[] = 2
>
> magically do someunknownlist = list() and append 2.


I hope you're being sarcastic.

If not, why don't you like:

some_list = [2]
--
Benji York
 
Reply With Quote
 
Ron Adam
Guest
Posts: n/a
 
      07-06-2005
Ron Adam wrote:

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


I retract this.

It's not a good idea. But assigning to None as a way to unbind a name
may still be an option.

 
Reply With Quote
 
Reinhold Birkenfeld
Guest
Posts: n/a
 
      07-06-2005
Ron Adam wrote:
> Ron Adam wrote:
>
>> And accessing an undefined name returned None instead of a NameError?

>
> I retract this.
>
> It's not a good idea. But assigning to None as a way to unbind a name
> may still be an option.


IMO, it isn't. This would completely preclude the usage of None as a value.
None is mostly used as a "null value". The most prominent example is default
function arguments:

def foo(bar, baz=None):

With None unbinding the name, what would you suggest should happen? baz being
undefined in the function scope?

Or, what should happen for

somedict[1] = None

The same as

del somedict[1]

? Also, the concept of _assigning_ something to a name to actually _unassign_
the name is completely wrong.

Of course, this is a possible way to unassign names if (and only if)
(1) there is a real "undefined" value (not None)
(2) unbound names return the undefined value

Look at Perl. Do we want to be like that?

Reinhold
 
Reply With Quote
 
Ron Adam
Guest
Posts: n/a
 
      07-06-2005
Reinhold Birkenfeld wrote:

> Ron Adam wrote:
>
>>Ron Adam wrote:
>>
>>
>>>And accessing an undefined name returned None instead of a NameError?

>>
>>I retract this.
>>
>>It's not a good idea. But assigning to None as a way to unbind a name
>>may still be an option.

>
> IMO, it isn't. This would completely preclude the usage of None as a value.
> None is mostly used as a "null value". The most prominent example is default
> function arguments:
>
> def foo(bar, baz=None):
>
> With None unbinding the name, what would you suggest should happen? baz being
> undefined in the function scope?


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

If it's an object... I suppose that would be None... Oh well.

> Or, what should happen for
>
> somedict[1] = None


Remove the key of course.

var = somedict[1] Would then give an error.

and

(somedict[1] == None) Would evaluate to True.


> ? Also, the concept of _assigning_ something to a name to actually _unassign_
> the name is completely wrong.


That's not anymore wrong than ([] == [None]) --> False.

Having a None value remove a name binding could make the above condition
True.

> Of course, this is a possible way to unassign names if (and only if)
> (1) there is a real "undefined" value (not None)
> (2) unbound names return the undefined value
>
> Look at Perl. Do we want to be like that?
>
> Reinhold


The problem I had with perl is that number of symbols and ways of
combining them can be quite confusing when you don't use it often. So
it's either a language you use all the time... or avoid.

Anyway, there seems to be enough subtle side effects both small and
large to discount the idea. While implementing it may be possible, it
would require a number of other changes as well as a different way of
thinking about it, so I expect it would be disliked quite a bit.

Cheers,
Ron
 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      07-06-2005
On 2005-07-06, Ron Adam <(E-Mail Removed)> 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.

--
Grant Edwards grante Yow! I've read SEVEN
at MILLION books!!
visi.com
 
Reply With Quote
 
Ron Adam
Guest
Posts: n/a
 
      07-07-2005
Grant Edwards wrote:

> On 2005-07-06, Ron Adam <(E-Mail Removed)> 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?

If a value isn't established yet, then do you need the name defined?
Wouldn't it be better to wait until you need the name then give it a value?



 
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
When (and why) to use del? Albert Hopkins Python 5 12-09-2008 08:27 PM
after del list , when I use it again, prompt 'not defined'.how could i delete its element,but not itself? python Python 7 06-03-2006 05:08 PM
Home server cases and external firewire cases thingy@nowhere.commy NZ Computing 5 03-14-2006 07:56 AM
How to become good in Documentation and use cases Patrick.O.Ige ASP .Net 1 12-11-2005 02:39 AM
Use Cases -- A minimalist's View Uncle Bob (Robert C. Martin) Java 0 07-02-2003 02:45 PM



Advertisments