Deleting variables [was Re: map/filter/reduce/lambda opinions and background unscientific mini-survey]

[Tom Anderson]

On Thu, 7 Jul 2005, Steven D'Aprano wrote:

> On Wed, 06 Jul 2005 14:28:55 +0100, Tom Anderson wrote:
>
>>> del -> delete
>>
>> How about just getting rid of del? Removal from collections could be done
>> with a method call,
>
> Which would be called object.del() I presume.

That would be fine.

> And that opens a big can of worms.
>
> Suppose we have a list L = [4, 3, 2, 1, 0], what should L.del(1) do?

Delete the item at index 1, just as del L[1] would.

> It looks like it should result in L becoming [4, 3, 2, 0].

Why? I guess if you hadn't read the documentation and were just calling 
methods at random, you might, but i can't think of any other case.

> An easy mistake to make, if you forget that the argument is (presumably) 
> an index.

Not the kind of thing people tend to forget! There is the problem that 
people might get del and remove mixed up; i didn't actually realise there 
was a remove method on lists until i looked just now.

> You could make it clear by insisting on L.del[1] but that requires a big 
> change in Python's syntax.

It would, so i wouldn't dream of insisting on it.

> What should L.del() do, with no arguments? Raise an error?

Er, exactly the same as calling any other method with a wrong-length 
argument list - a TypeError, i should think.

> Now, you have something like this:
>
> class thing:
>    pass
> obj = thing()
> obj.alpha = [4, 3, 2, 1, 0]
> obj.beta = 5
>
> Python's object model suggests that obj.alpha.del() should call alpha's 
> del method, in the same way that obj.alpha.append() would call alpha's 
> append method.

Exactly so.

> So how do you delete obj.alpha? obj.del("alpha") might work. But what if 
> obj itself is a mapping, with a key "alpha" as well as an attribute 
> alpha. Which one should obj.del("alpha") delete?

I don't think objects should have a del method by default. I'd suggest a 
delattr or removeattr builtin, working along the lines of getattr and 
setattr, for this task.

> Now, if you said that L.del() should raise an exception earlier, what 
> about obj.beta.del()?

Unless int has a del method, that would be an exception - an 
AttributeError, to be precise.

> Presumably every object automatically has a del method,

I'd say no, but for the sake of argument, let's say it does.

> so you don't have to program a del method yourself. obj.del is a method 
> object. So it has a del method. (Yes, sometimes you want to delete 
> methods. Functions are first class objects in Python.) Which has a del 
> method. Which has a del method.

Right.

> What should obj.del.del.del.del.del.del.del.del.del() do?

Raise a TypeError, since you haven't passed any parameters.

As for obj.del.del.del.del.del.del.del.del.del("del"), that's an 
interesting one - it comes down to the question of whether those del 
methods are the same object or not. I'd say not: for two objects a and b 
of the same class, a.foo and b.foo are considered different objects in 
python, and that applies here.

>> and i'm not convinced that deleting variables is something we really 
>> need to be able to do (most other languages manage without it).
>
> Most other languages don't have namespaces that can get polluted, or
> on-the-fly creation of variables. Most other languages don't consider
> variables to be simply attributes of a module object.

How much is that really used? And how many of those cases wouldn't be 
covered by a delattr builtin?

> And most other languages don't allow you to run interactive sessions 
> where it is easy to mistakenly make variables you don't want.
>
> py> x = 1
> py> u = x+2  # oops, typo, meant y not u
> py> del u  # prevent confusion in the programmer's mind
>
> It is also useful sometimes to delete a module object from the top level 
> namespace before re-importing it, rather than merely reloading it. That 
> requires being able to delete a variable.

That's a very strong use case. However, it would be straightforward to 
make variable deletion an interpreter thing rather than a language thing.

> In summary: del being a keyword works. del() being an object method is 
> unclear, confusing and complicated.

Only if you give it the bizarre semantics you use above!

I think having del as a keyword is actually unhelpful, since it's 
overloaded to do two quite different things - remove items from lists and 
dicts, and expunge attributes from namespaces. Far better to do let lists 
and dicts expose methods to let themselves be manipulated, and to play 
with attributes through a uniform troika of {get, set, del}attr builtins.

tom

-- 
They travel the world in their ice cream van ...