Musings about Python syntax

[Eric Jacobs]

steve_allison at my-deja.com wrote:
> 
> Hello all,
> 
> I've been working through the Python tutorial, and a have a few queries
> about the syntax of Python.  Python seems to me to basically be a very
> nicely constructed language, but I have been wondering about a few
> (seeming) syntactic anomalies:
> 
> i) if Python is as object orientated as is claimed, why are things like
> len() not member functions of list/tuples ?

Because tuples and strings don't have member functions. Lists do, but
it is kept that way so that the syntax is the same for all three. In
future version we might see strings and tuples having member functions
also (there's no reason why they can't.)
 
> ii) similarly, why is 'del' operator like, and not a member function of
> those types that support it ?  having an 'append' method, but a 'del'
> operator seems peculiar.

Why have d[2] = 500, and not force something like d.setitem(2,500)?

Actually, there is a syntactic symmetry here which is actually kind of
neat (although probably of little practical value.) The argument to the
del operator is an l-value. That's syntactically the same thing as what
appears to the left of an equal sign in assignment statement. So del is
really the opposite of the assignment statement.

	d[2] = 500			del d[2]

If d is a Python object, those would be the same as

	d.__setitem__(2,500)		d.__delitem__(2)

(For built-in types, it goes to PySequence_GetItem/DelItem in the C
interface, but the idea is the same.)

del is also used to remove variables from the local namespace,
using the same analogy:

	x = 2				del x

Here, I can't think of any acceptable alternative to using the del
operator. You might think of it as being like:

	del locals()['x']
or
	locals().__delitem__('x')

but neither of these is legal Python (the first won't work in a
function.) Nor are they particularly pretty. So it makes sense
to have the del operator as long as we have the traditional l=r
assignment syntax.
 
> Are these historical artefacts, or is the language designed liek tis
> for a reason ?  If so some can someone tell me the reasoning behind
> this scheme ?  I have mostly really liked what I've seen of Python so
> far, but niggles like these are really annoying me!

Python doesn't claim to be a pure object-oriented language, in the
way that, say, Smalltalk is. So in a sense, these are artifacts. They
simply reflect our arbritrary conventions for writing mathematical
expressions and programming constructs. Python places more emphasis
on readability rather than object-oriented purity in this regard, and
I think it's a good compromise. There's a kind of novelty in writing
if statements as methods of True and False objects, but when you want
to write good, readable, understandable code, it's best to use the
traditional if-then-else paradigm. I'll take 2+3 over 2.add(3) any
day, impure though it may be.