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
-- http://mail.python.org/mailman/listinfo/python-list
