why del is not a function or method?

[Chris Angelico]

On Tue, Oct 17, 2017 at 3:18 AM, Stefan Ram <ram at zedat.fu-berlin.de> wrote:
> bartc <bc at freeuk.com> writes:
>>What about del team[2]?
>
>   All arguments of a call are evaluated before the callable
>   called then is incarnated with the values obtained. Assume,
>   »team[ 2 ]« is bound to »8«. Then, the call
>
> f( team[ 2 ])«
>
>   is equivalent to
>
> f( 8 )
>
>   , and so »f« doesn't stand a chance of deleting »team[ 2 ]«.
>
>   The evaluation rules for calls do not apply to the del-
>   statement, however. Therefore,
>
> del team[ 2 ]
>
>   is /not/ equivalent to
>
> del 8
>
>   , and »del« can delete »team[ 2 ]« just fine. (Because the
>   implementation can use whatever means available to it,
>   since it is not bound to follow the evaluation rules for
>   callables.)

Right, but you *could* implement a function that takes the two parts
and does the assignment or deletion:

def f(lst, idx):
    del lst[idx]

f(team, 2)

The reason that 'del' absolutely has to be a statement is that it can
work on simple names, too:

del team

There's no way to do THAT part with a function call (it's basically
the opposite of assignment), so 'del' has to be a statement. Since
it's a statement, it may as well be able to do more than just simple
names, which means we have a consistent way to delete items from
arbitrary objects:

del globals()["foo"] # dicts
del sys.argv[1] # lists
etc

(Although you can't do this with sets. Sets are manipulated
exclusively through methods and operators.)

ChrisA