Tao of the Machine

Programming, Python, my projects, card games, books, music, Zoids, bettas, manga, cool stuff, and whatever comes to mind.

More O2 news

After successfully compiling the socket module yesterday, today I added the termios module. Fortunately this was quite easy, since the fix had already been discussed on python-dev.

I also looked at a few Irix-related bugs on Sourceforge, and commented on one, but my help will probably be of limited value, since I didn't encounter any of these problems/errors. I can upload the binary, though, if anyone is interested.

Posted by Hans Nowak on 2003-10-30 23:37:28   {link}
Categories: SGI, Python

Short O2 news

Slowly but surely I'm exploring Unix (or IRIX, to be precise). Unix is very powerful, but not always easy, and documentation can be sparse. Fortunately, there's always Google.

I managed to remap some keys in the bash shell, using the .inputrc file. I can imagine that, if you don't know where to start, this can be very hard to figure out. (man readline tells you more, but how would you know that you need that man page?) Anyway, I mapped Ctrl-Up and Ctrl-Down to do a "history search", much like I'm used to use in 4DOS and 4NT. Home and End cannot be mapped, for some reason; I tried various combinations, but they don't work, and no key code shows up in cat.

As for Python... Last time, the _socket module wouldn't compile. For some reason, u_long and u_char were not defined in /usr/include/netinet/tcp.h, nor in a Python file (getaddrinfo.c, IIRC). Fortunately, this was easily fixed by adding #defines in the right places. I also added a bunch of other modules, and sgi, so now I have a more complete Python on the O2. Much nicer. ^_^ Nobody likes a crippled Python.

The system is slowly becoming usable now. Maybe I can start hacking on my projects soon... that would be more than I could on the Mac. (I miss it, but I won't go back anytime soon.)

Posted by Hans "does SGI have an Ellen Feiss?" Nowak on 2003-10-30 00:41:47   {link}
Categories: SGI

The prodigal son

If everything goes as planned, I will be visiting the Netherlands again in December. I have been gone for two years now. A lot has happened while I was away... a change of currency, the rise of the extreme right, the first assassination in centuries, two elections, etc. On a more personal level, my parents moved, so I will probably not have the feeling that I'm coming home. :-/

For 28 years, I, like most other Dutch, judged the US by how the media portrayed them -- often negatively. But when you actually live in the States, you get an entirely different view. People make the mistake of projecting their (in my case, Dutch) morals and values on American society, which is usually not a good match. For example, owning a gun may not make sense in the Netherlands, but it makes a lot more sense here in rural Florida. (That doesn't mean that I've suddenly become pro-guns. Don't expect any rabid rants from me about the right to be "armed and dangerous". <wink> But what I'm trying to say is, I can think of reasons why people would want to own a gun, in this environment.)

Funny thing is, for the last two years my image of the Netherlands has only been fed by news from various media, rather than by actually living there. If a foreigner would go only by what the media write about the Netherlands, they would get a very strange picture indeed... disturbing, possibly, and incoherent due to mixed signals. Because, what have been the major news items? Assassination. Strange laws where a store's employees are convicted because they catch a thief. Royal house issues: one prince marries a woman who is tied to Argentina's Videla regime, another marries one who might have been a gangster's girlfriend. Then there's rampant racism, and the rise of right-wing parties. Others say, they're not really on the extreme right, and it's Moroccans who cause a lot of trouble. Economical recession. "Pointless violence" (zinloos geweld). All this on top of the already dubious image of the Netherlands (Amsterdam = drugs).

The impact of these portrayals in the media are such, that even I, a native Dutchman, would almost think that it has become an unsafe and wacky place to live. Almost. I hope I'm wrong. Last time I checked, not everybody in the Netherlands used drugs, much like not every American walks around with a gun or a cowboy hat. In fact, I've seen more drug addicts in Florida than in the 'lands. And I hear about more shootings in the Netherlands than I do here. It's a strange world.

Posted by Hans Nowak on 2003-10-30 00:12:05   {link}
Categories: general

Smart keywords in Firebird

Mozilla Firebird (nee Phoenix) has been my browser of choice for a while now. Overall, I am very content with it. Sure, there are some nitpicks; it can be very slow sometimes, for example. Also, there's one feature I'd like to use, but it doesn't seem to work: smart keywords.

The "Why Mozilla Firebird" page mentions smart keywords. Apparently looking a word up in the dictionary is as easy as typing "dict something" in the location bar... except that it doesn't work. The page suggests that words are looked up at dictionary.com, but rather, it seems that it does a Google "I'm feeling lucky" search. (A feature which is cool and useful in its own right, by the way.) If you're lucky, you get the word definition from one dictionary site or another; otherwise you get something else entirely. dict firebird leads to a word definition, but at die.net. dict spindrift leads to a page has a list of words, but it is is no dictionary at all. dict python leads to... a weblog post by Matt Croydon!

Using "dict:" instead doesn't work either: "dict is not a registered protocol". So what's going on here? The Mozilla page points to two other pages that are supposed to have a list of available keywords, and instructions for how to make your own keywords, but both show "I have no written this page yet". Hmmm.

I noticed this problem in version 0.6. I now have 0.7, but it still doesn't work. It's possible that the problem is on my side, that I somehow have the wrong versions of certain files or something, but I'm not so sure... the other new features seem to work just fine.

Update: Several people pointed out that this should be in Bookmarks > Quick Searches, and that it's easy to add. Indeed it is, and now I know how to add my own keywords. One of the nice things of open source software is that it's open in more than one way... it's often highly configurable. ^_^

Update 2: Some useful keywords, contributed by a reader who calls himself Follower:

  • ggt: http://translate.google.com/translate?u=%s
  • ggc: http://www.google.com/search?q=cache:%s
  • ggg: http://groups.google.com/groups?q=%s
  • gg: http://www.google.com/search?q=%s
  • pydoc: http://web.pydoc.org/2.2/search.cgi?key=%s
  • clp: http://groups.google.com/groups?meta=group%3Dcomp.lang.python.*&q=%s

Posted by Hans Nowak on 2003-10-29 11:18:22   {link}
Categories: general


I've been experimenting a bit with elastiC, now that I have a working version on IRIX. Some thoughts follow.

  • elastiC is an interpreted language. It allows for bytecode compilation, much like Python. Its syntax and features are inspired by C, Python and Smalltalk.

  • The online documentation is lacking, unfortunately. Apparently this is still very much a work in progress, like the language itself. Many crucial parts are missing, making it difficult to learn the language. There's a page with examples, which is a bit of a help, but it's not sufficient to learn the basics.

  • Lists and dicts are available. They have different names (arrays and hashes) and look a bit different, but they seem pretty much equivalent to Python's. Lists look like this: %[1, 2, "foo"]. Dicts look like %["bob", 45, "john", 56]. (As I noted in my previous post, these are key/value pairs.)

  • elastiC supports symbols as well. They look like #this.

  • elastiC OO seems to be borrowed from various languages. Classes allow for private attributes; instance variables are declared in the class body, much like C++ or Java. Methods and attributes are different beasts; attribute access is done with obj.name, while a method call is done with [obj name parameters] (e.g. [point translate 3, 4]). (There seems to be no way to access a method without calling it.) Methods can be defined and called with Smalltalk-like syntax as well: [obj drawLineFrom: pointA To: pointB]. self is implicit. Oh, elastiC supports class methods as well. And magic methods, although I've only seen a few so far (init, _getitem and _setitem).

  • Something strange is going on with elastiC's methods. I defined a class Point with an init (like Python's __init__) with two parameters. Calling [Point new] worked, though. I would have expected an error. Adding another version with no parameters didn't work; apparently elastiC doesn't do method overloading like C++, but why is the mismatching init called anyway? That doesn't seem right.

  • elastiC is dynamic, although not as much as Python. As far as I can tell, it supports functions as first-class objects, but not methods. (I could be wrong, but these things are not obvious from the documentation.)

  • The language has modules. For some reason, the program you're running is a module too, and must have a "package" header (e.g. package hello; for the program hello.ec). I'm not sure if module names are resolved from the package statement, or the filename, or both. Both seems redundant.

I think elastiC is an interesting language, but it's not ready for serious work. Sadly, not much development seems to be going on lately. Version 0.0.37 is more than a year old, and the mailing lists are desolate. And since the documentation is not complete, learning the finer points of the language is very difficult.

Posted by Hans Nowak on 2003-10-27 23:57:28   {link}
Categories: programming

What makes Python readable?

Following up on my 'Changes' posts... what is it exactly, that makes Python code so readable? Here are some thoughts.

Code is different from text we usually read in books, magazines or web pages. 1) Yet I think it's important that the code format resembles "normal" text, within reason. If there is no equivalent in everyday text, then other "standards" can be used as well. For example, the C language is quite common; when in doubt, borrowing syntax from C may be a good choice. When a language is designed with these informal rules in mind, its constructs will usually be perceived as "intuitive" and "unsurprising", because it connects to what people already know, rather than forcing them to learn new constructs.

So, what features does Python use to improve readability?

Accessor syntax. C uses a.x to get an attribute x from a struct a. It only seems natural that Python does the same, and it extends it to objects other than structs (classes, instances, modules). On top of that, the dot is visually non-intrusive and is not perceived as line noise. Imagine what Python code would look like if Guido had chosen a different character, e.g. a!x or a#x like in some other languages.

Commas. In regular text, commas are used to separate things, like (parts of) sentences, or items in a list. Python's usage of the comma in lists and tuples therefore feels natural. Omitting the commas doesn't feel right, at least not to me (although I'm sure Lispers would disagree); compare [apple, pear, banana] vs (apple pear banana).

Whitespace for code blocks. Probably the most conspicuous feature of Python. Many languages use { } for code blocks, but those characters are not used a lot in everyday text and therefore feel like line noise. Using begin and end is clear, but verbose. Both constructs tend to waste lines. Python's indentation-based blocks are an interesting alternative, allowing for code that is compact but extremely clear.

Colons. In everyday text, colons serve a purpose that is not unimportant: they indicate that a clarification follows. Some people think the colon at the end of a function header (or if, for, etc) is redundant. Syntactically, this may or may not be true, but to me, a line like

def foo(bar, baz):

clearly says: here's a function foo, and this is its implementation. It just seems stronger and clearer than without the colon.

":" is also used in dictionary literals. {"bob": 45, "john": 56} for example. Here, using the colon to separate key/value pairs seems a good choice as well. In elastiC, this would be written as %["bob", 45, "john", 56], which, upon casual reading, doesn't imply a relationship between bob and 45, or john and 56 at all.

Square brackets. These are used for list literals, and for indexing. Considering that (1, 2, 3) already has a meaning (it's a tuple), [1, 2, 3] seems the next best choice. As an indexing construct, it's borrowed from C (I assume); again, a[i] seems better and clearer than, say, a!i. (But this seems to be mostly a matter of what people are used to. If Dennis Ritchie had chosen a!i for C's index notation, then that would probably be considered more intuitive nowadays.)

Curly braces. These are used for dictionary literals. Those are not uncommon, but still less common than code blocks, so there's not so much line noise involved when you write dict literals.

No semicolons. Python does have semicolons, of course, but they are used to separate statements on the same line, a practice which is discouraged and thus not very common. Python lines do not end in a semicolon, which reduces a bit of line noise; usage of ";" as a terminator is not very intuitive, by the way, because in regular text it is not used at the end of a sentence. (A dot would be better in this respect; I believe Prolog does this.)

Fewer "line noise" characters. Guido deliberately tries to avoid characters that aren't used a lot in everyday text. @ and $ aren't used at all; neither is ? (which *could* serve a purpose in variable names). Some constructs are borrowed from C, like the binary operators &, | and ^. This doesn't affect readability much, because they aren't used very often. Whenever possible, a keyword is used rather than special characters: not instead of !, and instead of &&, or instead of ||. Other characters, like the backtick and the backslash, are used sparingly.

All these features together make Python code extremely easy to gloss over. I don't know much about usability studies, but my pet theory is that every bit of line noise is a tiny little hurdle, something that requires a few extra brain cycles to figure out what's going on.

Of course, readability goes hand in hand with the ability to understand code. Python does its best there, too; it would be much less readable if the language was highly irregular, inconsistent or context-sensitive. But that is something for another day...

1) "Text we usually read", implying English, or other Western European languages. I realize that this view is biased and that a Japanese's notion of "normal text", for example, would be very different.

Posted by Hans Nowak on 2003-10-27 09:57:10   {link}
Categories: Python

Changes (2)

In spite of the impression some people might get when reading this weblog, I am not against all proposed changes to Python. emoticon:smile

Here's one I like: an extra keyword for list.sort() to support the common "decorate-sort-undecorate" idiom. (python-dev discussion; start here) This feature is small, non-intrusive, and very useful. When added to tutorials, it will also teach newbies to do the right thing (as opposed to teaching them the D-S-U idiom, which is clumsy). Also, if you don't know the idiom, you're likely to use a comparison function and run into performance problems for large lists. This makes this feature non-trivial.

The aforementioned thread has interesting stuff, besides the proposal; why DSU in its regular form is a bad choice for sorting large lists of database keys, for example (the correct way to do it is provided as well).

Also, a (possibly misquoted) saying attributed to Tim Peters:

Adding trivial functions is a net loss because the burden of learning or becoming aware of them (and their implementation nuances) will far exceed the microscopic benefit of saving a line or two that could be coded on the spot as needed.

This is exactly the problem I have with adding things like sum and the proposed list.sorted. Apparently people don't consider them 'trivial' for some reason. (Update: For arguments in favor of list.sorted, which were received favorably by Guido, see this post.)

list.sorted comes from another discussion about list.sort (starts here). Interesting quotes here too:

[Tim Peters]
That said, since we're having a fire sale on optional sort arguments in 2.4, I wouldn't oppose an optional Boolean argument you could explicit set to have x.sort() return x. For example,
>>> [1, 2, 3].sort(happy_guido=False)
[1, 2, 3]

Posted by Hans Nowak on 2003-10-26 12:39:50   {link}
Categories: Python


Since gouramis are labyrinth fish as well (like bettas), I wonder if that means that you can keep them in a bowl as well? Without a filter and all that good stuff? This site seems to think so. (Although the guy says you don't have to change the water at all; I wouldn't go that far.) AquariumFish recommends an aquarium, though.

Posted by Hans "if there's room for 20 fish, there's room for 21" Nowak on 2003-10-25 23:07:03   {link}
Categories: bettas

Generated by Firedrop2.