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?

ChaosNET and Python

My blogging has been much less frequent of late, mostly because of an unfortunate abundance of non-computer issues. Despite those, I believe I have made some progress in my Chaosnet-on-OpenMCL work, but I’ve switched most of my hobby-development to Python, mostly to get in touch with trends outside the Lisp Universe.

My current main project circulates around ChaosNET emulation; the main thing going for Python here is a socket interface that is roughly compatible between UNIX-like and Windows operating systems. Lisp can support that as well, but not for my favorite and familiar implementations. (One thing I hope to try before I get through this is to get an asyncore-like framework set up in CLISP.)

So far, I have implemented a `chaosd’ process in Python that simulates multiple ChaosNET `ethers’ in the form of localhost TCP streams (on Windows or UNIX-like) or UNIX-domain sockets (on UNIX-like); each stream corresponds to a subnet. The idea has manifold goals:

• Allow the usim CADR simulator to communicate on Windows with minimal alterations using Winsock in place of BSD sockets (Done) (Brad Parker’s server, however, works with forking and other UNIXisms that would require more work)
• Allow separation between local activity and activity exposed or connected to the wider Internet
• Provide ‘masquerade’ and ‘network translation’ bridges, to flexibly map external resources, such as an ITS or TOPS-20 simulator into something that appears to be a local network. (The translation here is necessary because ChaosNET is a LAN architecture; outside resources might have their own incompatible scheme of subnetting and addressing. These translating gateways would allow me to place external UDP-responding resources into arbitrary Chaos addresses in my local scheme, without requiring any change on the external resource.)
• Eventually, provide small modular `gateway’ simulators that appear to be ChaosNET resources on a local subnet, but translate to external services such as AOL Instant Messenger or IRC.
• Recreate `historically accurate’ network organizations for amusement
• If I ever break down and get a real Symbolics machine, I expect it to be able to speak Chaos over IP or raw Ethernet; I would like some way to connect that to multiple simulators on a single Mac or PC

As a step in this direction, I have implemented a stream-to-UDP masquerade, that automatically takes traffic on a local `ether’ for a particular address and feeds it over UDP using Bjorn Victor’s protocol. Running this on two machines, I am able (mostly) to allow a Lisp machine simulator on my Linux box and another on my Windows box to both believe they are on a single Chaosnet LAN, and to communicate with one another. The next step is to get something like a local ITS or TOPS-20 simulator running in KLH-10 on Linux supporting Bjorn’s UDP protocol (or possibly Bjorn’s machine) to provide FILE service and e-mail service to my Lisp machine simulators on either machine. I have been learning to recompile ITS, with mixed success. My initial impressions on Python in another post.