Why is del(ete) a statement instead of a method?

[John Roth]

"Tim Roberts" <timr at probo.com> wrote in message
news:hg6aqug7cubnsg45tf1cadtdia9vql2gjk at 4ax.com...
> Padraig Brady <Padraig at Linux.ie> wrote:
> >
> >Being a python newbie myself this strck me as a little inconsistent.
> >
> >why can't you do:
> >
> >l=[1,2,3]
> >s="123"
> >i=123
> >
> >l[1].del()
> >l.del()
> >s.del()
> >i.del()
>
> The way I see it, THOSE are inconsistent.  Think about it in an
> object-oriented way.  It doesn't make sense to ask an object to
"delete"
> itself, because the object isn't in control of where it is stored.
You
> have to ask the OWNER of the object to do the delete.  It's the OWNER
that
> has to take an action.  Thus, something like "l.del([1])" would be a
bit
> more consistent.

It isn't even an OO issue. It's a binding issue. If you let an object
delete itself, you risk having dangling pointers all over the place.

So the first example is legitimate: it's asking the container object to
delete one of the elements in the container. The other two examples
aren't.

However, there's another issue here, although it's also an
inconsistency.
Delete in the first example is the inverse of insert or append, right?
Insert is done with special assignment syntax that also allows deletion.
Append, however, is a method that does one very strange thing: it
returns
None instead of the object, so it can't be chained properly. Adding a
.delete method would simply exascebrate this assymetry.

John Roth