Python becoming less Lisp-like

[Valentino Volonghi aka Dialtone]

Bruno Desthuilliers <bdesth.quelquechose at free.quelquepart.fr> wrote:

> A few examples:
> - A statement is different from an expression (2 special cases instead
> of one general case).

> - You can't use statements in a lambda

Good reason to remove lambda, let's do this asap.

> - to get the length of a sequence, you use len(seq) instead of seq.len()

I can see nothing wrong with this.
seq.__len__() 
works equally well.

> - to call objects attributes by name, you use [get|set]attr(obj, name
> [,value]) instead of obj.[get|set]attr(name [,value])

this is the same as above. And I can see nothing wrong with this. This
is not a special case but syntax sugar. If you feel more comfortable use
the following:

seq.__getattribute__('append')
<built-in method append of list object at 0x55fb48>

> - if x is a class attribute of class A and a is an instance of A, 
> a.x=anyvalue create a new instance attribute x instead of modifying A.x

How is this a wart? Do you understand mutable and immutable objects?

In [7]: class A(object):
   ...:     a = {}
   ...:     b = 5 
   ...:     

In [8]: a = A()

In [9]: b = A()


# Modifying an immutable object yields a new object, thus a new binding
In [10]: a.b = 3

In [11]: b.b
Out[11]: 5

# Modyfing a mutable object doesn't change the original binding:
In [12]: a.a['a'] = 4

In [13]: b.a
Out[13]: {'a': 4}

It would be a wart if it was like you thought it should be because the
behaviour of objects changed depending on where they happend to be.

> - sequence methods that modify the sequence in place return None instead
> of returning self - ok, I know the rational for this one, but I still
> dont like it, and still count it as a special case since when using a
> 'destructive' sequence method I can't chain it with non-destructive 
> method calls.

This has nothing to do with special cases... Your countless special
cases are coming out to be things you didn't really understand about
python.

> - object.__getattr__ (if it exists...) is called only when attribute 
> name is not found. object.__setattr__ (if it exists...) is always called.

This is because of the new object model. Agree here, there should be
only one: __getattr__ or __getattribute__.

> - functions are not methods

functions are functions and methods are functions that take the instance
of the object as their first argument. Anyway discussion is ongoing to
remove the bound/unbound difference. Though you can actually do this:

In [14]: class A(object):
   ....:     def foo(self, a):
   ....:         print "hello world"
   ....:         

In [15]: a = A()

In [16]: a.foo(1)
hello world

In [17]: def baz():
   ....:                 
KeyboardInterrupt

In [17]: def baz(self):
   ....:     print "hello world"
   ....:     

In [18]: a.foo = baz.__get__(a)

In [19]: a.foo() 
hello world

> - old-style classes vs new-style classes

Agreed. Backwards compatibility wins here. Again Python 3k will remove
this.

Of all your points I agreed on only 3 or 4. This strikes me as a very
well thought out language that in 15 years managed to only get 3 or 4
special cases.

> Also, Python enforce some coding style (indentation) but not some others
> (capitalization for example). So you always have to check, on a lib by

you are mixing oranges and apples here.

> lib base, what style has been used (I personnaly don't give a damn 
> whether I use underscore_all_lower or mixedCaps, but consistency is 
> useful, even more when there's such a huge stdlib). Worst, the base 
> class for new style classes is all lower ('object') when the usual 
> convention is to use CamelCase for classes.

Python standard library is consistent with this style. The only library
I am aware of that doesn't follow this style is wxPython with wax, and I
always discurage every python developer to use this library for this
very reason. I can agree with you here, but this is not a special case.

> I'm not able to count them all, since a good part of them are not carved
> in my poor little brain - I just deal with them day after day. I love

You are not able to count them all since there are almost not special
cases. But many things that could be done in a better way (this is for
sure, python is far from perfect, but it 'sucks' a lot less then
everything else).

-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de