Python becoming less Lisp-like

[Jeff Shannon]

Bruno Desthuilliers wrote:

> A few examples:
[...]
> - to get the length of a sequence, you use len(seq) instead of seq.len()
> - to call objects attributes by name, you use [get|set]attr(obj, name 
> [,value]) instead of obj.[get|set]attr(name [,value])

These are both very consistent applications of a more functional style 
of programming, rather than the pure object-oriented style you seem to 
desire.  It's not that Python is inconsistent; it's that Python is 
consistently blending multiple paradigms in a way that uses the best 
features of each and (mostly) avoids the worst pitfalls of each.

> - 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

This is very consistent with the way that binding a name in any scope 
will shadow any bindings of that name in "higher" scopes.  It is the 
same principle by which one is able to use the same name for a 
function-local variable that is used for a global variable, without 
destroying that global variable.  Doing as you suggest would be far 
*less* consistent, and would create a special case for class/instance 
lookups where there is none now.

> - 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 is not a special case.  It is a deliberate and consistent design 
decision, and it is implemented uniformly through the standard 
library.  Note that if your preference was the standard, one could 
*still* use the same logic to call it a special case -- that in some 
cases a method call returns a new object leaving the original 
unmodified, and in other cases it modifies the original object and 
returns a reference to it.  The current implementation has the 
advantage of being much less likely to lead to hard-to-detect bugs 
than your preference would.

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

Um... does Lisp enforce capitalization?  No.  Does C? I didn't think 
so.  Keep in mind that Python uses indentation not as a coding style, 
but as an inherent part of the syntax in the same way that C uses {} 
(but that indentation is much easier for humans to keep straight).  Do 
you complain that C enforces brace-usage but not capitalization styles?

What you have here is a listing of things about Python that you don't 
like.  They are not actually special cases, except in the sense of 
"things that Bruno especially dislikes".  Now, you're welcome to 
dislike them if you want, but be aware that some of the things that 
you're looking at as weaknesses, others of us see as positive and 
beneficial things, and in many cases there's real evidence to support 
the contention that Python's design choices will decrease the 
frequency of bugs.

Perhaps Python *is* becoming less Lisp-like... but I've never been 
convinced that Lisp is the best of all possible programming languages, 
so maybe being less Lisp-like and more Python-like is a good thing.

Jeff Shannon