After reading the article entitled "Why Python is not my favorite language", I found that I disagreed with all three of the authors' points, except for maybe the first.
- Variable declarations would be nice. Requiring them
would need to be worked into a version of Python other than
3.0. In the next version of the 3.x series (excluding the
3.0.x series), perhaps a push toward the requirement could
be made. It might issue a warning when you used something
someVar = 'value'. At the point where it would be made a requirement, it would be an error/exception. But how would you declare it? After all, one of Python's biggest strengths is the fact that it is so dynamically typed. I'd suggest borrowing the '
var afor declarations (initialised to 0 perhaps?) or
var a = tuple(map(pow, *8, range(8)))for declarations with initialisers (the '
var' keyword wouldn't be required in function declarations because the fact that they're variables is implied).
- This is actually fixed in Python 3.0. In Python 3.0, there is a 'bytes' type for byte strings and there is a 'str' type for Unicode strings (in versions 2.5.x and older, the 'bytes' type was the native 'str' type and the Unicode string type was of type 'unicode'; version 2.6.x uses the bytes type natively, just like Python 2.5 and older, mapping it to the 'str' type). You can't compare strings and bytes since the comparisons for both are done lexicographically (and there is no telling what character encoding should be used to encode the string for comparison with the bytes value). It also disallows comparisons between strings and numbers, bytes and numbers, strings and lists, numbers and lists, etc. Only arbitrary objects are compared by their id (see the 'id' function). If you want them compared a different way, look into special comparison functions like object.__lt__. I'd recommend object.__cmp__ if it wasn't for the fact that it was phased out as of Python 3.0 in favour of the richer comparison functions.
- I actually prefer using "self" and "cls" for instance
and class methods respectively. After all, you would code
an object-oriented function that way in C anyway. One might
argue that even Objective-C does that:
MyObject *my_obj = [[MyObject alloc] init];
It could be a while before Python 3.0 makes its way onto mainstream Linux distros, especially those that have a reputation for being rock-solid and extremely stable as a result of not being "cutting-edge", it is most certainly a great upgrade to Python. It invalidates one of the issues, and it also makes older versions of Python seem outdated in my opinion. Coding in Python is great, if you can use it without too much frustration.