Early impressions on Python

Python isn’t so bad. However, I find myself bothered by a few issues.

  1. The development environments are not as Emacs-oriented as Lisp environments are. My default installations of Emacs don’t seem to come with Python mode, and I have mixed success doing SLIME-like development on Windows and Linux. For now, I use IDLE. I find it hard to view what is going on in the stepping debugger, including such basics as what line in the code I am currently stopped at, and have no apparent interactive inspection facility. (E.g. if I step through my code, I can see a local variable holds a dictionary, but see no way to expand the view so that I can see every entry in that dictionary, or to see the contents of objects contained in the dictionary.)
  2. Backtraces by default are limited in their description of the stack frames (also, Python’s documentation (proudly?) states that Python uses the termination model for error-handling, although rumor has it the backtrace stacks include more information than the default handler prints.) IPython might be better in this regard, but then I have to solve the editor integration puzzle again.
  3. Python is both more and less dynamic than Lisp
    1. The usual ‘mistyping leads to a brand new variable/attribute without warning’
    2. ‘reload’ doesn’t update current object instances to reflect a newer version of the class defintion. (The backtrace, however, will refer to the new code even when an error occurs in the old instance)
    3. property seems to grab only the getter and setter that are defined at that point in time on the class being defined. That is, if I define slotname=property(getter,setter), if I override getter or setter in a subclass, the property apparently uses the superclass getter and setter, unless I execute the property line in the subclass. That’s doable, but requires redundant typing.
    4. In general, it seems that definition forms in Python are designed to act pretty much as procedural code which acts by mutating state in dictionaries, etc., at definition time, and isn’t supposed to persist in ways that allow for redefinition to transparently replace old definitions, but are simply supposed to mutate the current dictionaries, etc., into the new form, orphaning anything that depended on the old form.
  4. Asyncore is like a red-headed stepchild. Ask a question about it, you hear ‘use Twisted.’ I can’t find a clear explanation of asyncore’s faults. What’s the point of ‘batteries included’ if everyone throws them out and uses other batteries?

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: