Efectos Especiales

Last year, Florida was hit by four hurricanes. During one of those hits, we were without power for more than 4 days. I balked, shocked that such a thing could happen in a civilized country. (Note: this was before Katrina showed that a hurricane can be much more devastating than just causing some power outage. In this light, the complaints about the 2004 hurricanes seem trivial. But bear with me.)

Since yesterday there has been heavy snowfall in the Netherlands. Because of this, one town has been without power for two nights now [article in Dutch]. (A power line broke, and it's too dangerous to fix it right now.)

So, yeah, power outages happen in the Netherlands too. They're rare, but they do happen. However... it seems that I am not the only one to be shocked by the notion of being without power (and water) for days. The mayor of Haaksbergen, the town without power, says: "I don't understand it either that a whole Dutch vicinity can be without power for two days. And even if that is the case, shouldn't there be enough means to keep things going?"

So I guess we're all spoiled where I come from. In some ways, the Netherlands are not such a bad place to live.

[Update #1] It appears that people (but not companies) will be compensated for the costs they incurred because of the outage. Compare that to the "system" here; not only did we not get compensation of any sort (even though I lost days of work), the power company even had the nerve to make the next bill *higher* than it actually was. (Artificially higher, by taking an average of some kind rather than using the real amount based on actual power used.)

Also, the Dutch government will investigate how this could happen.

If you're indecisive, TMTOWTDI is a terrible feature.

Read this article: Understanding Ruby symbols. (Pointed out to me by reader Jordan.)

Basically, Ruby creates a new string object for every string literal it encounters. So a list ["red", "red", "red"] will contain three different string objects:

irb(main):001:0> a = ["red", "red", "red"]
=> ["red", "red", "red"]
irb(main):003:0> a.map { |s| s.object_id }
=> [22458208, 22458196, 22458184]

I'm assuming this behavior exists for a reason, most likely because Ruby strings are mutable. In contrast, Python's are immutable, so the interpreter can afford to do some caching. That doesn't mean that it has to, though... I believe this behavior is implementation-dependent and not something you can rely on between versions.

>>> a = ["red", "red", "red"]
>>> map(id, a)
[9311424, 9311424, 9311424]

Sure enough, they all have the same id, so it's the same object. Let's test some more, for example with a dictionary:

Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> a = {"sesquipedalian": "long", "python": "whitespace"}
>>> b = {"sesquipedalian": "huh?", "python": "snake"}
>>> [id(x) for x in a.keys()]
[9311424, 9304888]
>>> [id(x) for x in b.keys()]
[9311424, 9304888]
>>> id("sesquipedalian")
9304888
>>> s = "sesquipedalian"
>>> id(s)
9304888

It isn't until we try a different string creation method that we get a different id:

>>> t = "sesqui" + "pedalian"
>>> id(t)
9304928

So, in other words:

• In Ruby, symbols are useful because they are reusable, possibly saving lots of memory. They're also immutable. They provide a useful alternative to the mutable strings.
• In Python, symbols would not be useful for that reason, because it has immutable strings, and implementations are able (although not required) to cache values for reuse.

This thread about adding symbols to Python is interesting.

I personally don't think Python needs symbols. Ruby has them, but they don't seem very useful there either. Sure, they *seem* nice, but upon closer inspection they can be replaced with strings in almost (?) all cases. In fact, in many Ruby idioms, strings can be substituted for symbols, and vice versa.

That said, if you really like this feature for whatever reason, then you can probably get most of the desired behavior by hacking around a bit (as opposed to adding it to the language proper). Here's a first stab at it. Warning: I didn't test it very well, and certainly didn't use it in any real code.

The Rails book is quite good. I don't know all that much yet about Ruby nor Rails, but whenever I want to add something to my website-in-development, all I have to do is look up the relevant term in the book's index, and it takes me to a clear explanation of the desired feature. I haven't yet come up short, in that the feature I wanted was missing (from either the book or Rails), or was explained insufficiently.

So, yeah, I am writing software for my new website... it won't be anything fancy, just blogs, articles, a comment system, etc. It's more for learning purposes than anything else. That's the main reason why I don't want to use an off-the-shelf system like Movable Type, Wordpress or Typo. I want to learn, and Rails is just the system to do it.

Nitpick: On the new site, I am definitely going to make sure that it's clear which comment link belongs to which post. The current design doesn't appear to be all that clear in that respect... several times people have added comments to the wrong post. *I* think it's pretty clear, but apparently it confuses people. :-( And a confusing design is a bad design.

By the way, the new software probably won't be open source. Not that I don't want to share it, but it's for personal purposes only; it's not meant to be yet another blogging tool or CMS. Also, since I am still learning, it probably won't be a brilliant example of competent web programming.

Also note that the new site, with the new weblog, won't be as Python-centered as this one or the previous one. I have discussed other languages before, but Python has always been the most important one. That might change in the new situation, because I want to experiment with other languages as well, and not just for 20-line programs. (We're talking *interesting* languages here, whether it be Ruby, Lisp, Scheme, Smalltalk, Erlang, OCaml, or whatever.)

The good news is that categories will be back, and will likely have their own feeds, so you can subscribe to (e.g.) the Python feed without having to suffer through my posts about Ruby, Ubuntu, cats, or astrology.

All this will be a while though... I just started developing the system, and the new subdomain isn't even set up yet. All in due time...

(And no, this isn't the weblogging system that was supposed to be "different". That project has been abandoned. It was a little *too* different, so much so that it was unusable. Don't ask what it did. :-)

As seen in these comments: "Here's some complementary stupidness: If you enter "quit" or "exit" in the Python interpreter, it will respond with "Use Ctrl-D (i.e. EOF) to exit.""

That is indeed annoying, but I figured there would be a good reason for it. It would have been trivial to add functions quit and/or exit that exit the interpreter, but maybe whoever designed this did not want to pollute the namespace.

However:

>>> exit
'Use Ctrl-Z plus Return to exit.'
>>> type(exit)
<type 'str'>
>>> type(quit)
<type 'str'>

exit and quit are just strings... in other words, the namespace is already "polluted", but rather than having these names refer to useful functions, they refer to strings that tell you the "right" way to exit.

To make matters more interesting, on Windows the "correct" key combination is Ctrl-Z, while on Unix it's Ctrl-D. This discrepancy annoys me no end, because I use both systems, so it's easy to use the wrong exit method. Typing Ctrl-D on Windows does not work, while typing Ctrl-Z on Unix suspends the interpreter rather than quitting it.

Why this behavior? The only reason that I can think of that is vaguely plausible, is that the designer did not want people to think that exit or quit are valid ways to leave Python. (Newbies might end up typing that in their programs, which of course won't work.)

I know that Ctrl-Z and Ctrl-D are supposed to represent EOF and EOT, so allowing them makes sense, but why not add a simple function as well so users aren't surprised or annoyed? I hate to say it, but Ruby got this right, by the way... typing exit in irb has the expected effect.

And, yes, I know, you can fix this by hacking site.py, for example. But why isn't this in there to begin with?

[Update #1] I noticed that my terminology was a bit imprecise. Of course, if exit is a function, then exit on the command line will result in something like "<function exit at 0x008DFBF0>". Rather, it should be an object that exits when it's evaluated. E.g.

>>> class _Exit:
...     def __repr__(self):
...         raise SystemExit
...
>>> exit = _Exit()
>>> exit # exits the interpreter

This behavior is rather hairy and maybe un-Pythonic (__repr__ is supposed to return a string, but raises an exception instead). Maybe that is the reason why it isn't implemented?

[Update #2]   !

Interesting...

Defectos Especiales

I've probably mentioned this before, but back in 2001, when the first Harry Potter movie was out, we went to the very first showing on the very first day. And nobody else was there. Nobody at all. We did the same thing for the second movie, and there were more people there, although it still wasn't a full house. Then for the third movie, there was a schoolbus (or maybe several) full of kids there, riled up by some guys from a radio station. ("When I make this sign, all the kids on the left say 'Harry', and the kids on the right say 'Potter'!")

Extrapolating this trend, it shouldn't come as a surprise that the fourth movie, which had its first showing in the US today, was sold out. Both Gator Cinemas and Regal were, and I was told that the latter had "school buses coming in all day".

[Insert silly rant here about stupid kids who should be in school and cinemas that alienate loyal fans who have been there since day one. ]

Anyway, so my best bet would be to wait until everybody has seen it, and then go to a showing early in the day, or so.

So the times that we could go to these movies and not be bothered by hordes of people are definitely over. I wonder what the Narnia movie will do? HP-2001 or HP-2005?

Upgrading Hoary to Breezy was not a breeze for me, no matter what kind of experiences others might have had. However, doing the upgrade while under the influence of painkillers might not have been the greatest idea.

At some point, Ubuntu claimed to have installed the breezy packages, but then all of sudden forgot to use Gnome as the desktop manager. Oh well. I ended up reinstalling from scratch; no big deal, because I didn't use the system very much anyway.

There are definitely some improvements since Hoary. For starters, Ubuntu now recognizes my video card and its resolutions (without having to dig for drivers first). There's also a package for wxPython 2.6, so my Windows and Linux systems are in sync again for Wax development. I also noticed a package for Rails (didn't see that in 5.04), etc. It also mounts my other hard disks automatically and correctly. In general, it was a smoother installation experience than before.

Sometimes you have to put things in such a way that your target audience can understand it... I guess.