Name: Dustin Boyd
Member since: 2009-04-24 00:13:28
Last Login: 2009-05-02 09:16:07

No personal information is available.

Recent blog entries by RpgFan

24 Apr 2009 (updated 24 Apr 2009 at 01:59 UTC) »

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.

  1. 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 like 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' keyword from JavaScript for declarations. Something like var a for declarations (initialised to 0 perhaps?) or var a = tuple(map(pow, [2]*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).
  2. 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.
  3. 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];
    The first part is "MyObject", the class itself. The second part is the method to call (since everything should inherit from Object or NSObject, everything should have an 'alloc' class method). An instance of class "MyObject" is returned, and the 'init' method is then called on that instance to initialise whatever is specified by the programmer (the combination of the 'alloc' and 'init' methods is analogous to the concept of a constructor function in other languages). Honestly, Python is no different.

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.


Others have certified RpgFan as follows:

  • chalst certified RpgFan as Apprentice
  • murajov certified RpgFan as Apprentice

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page