A Joke, or an Accident?

I can't decide whether Greg Wilson posted this as a joke. In case he didn't, and whatever error induced this behavior is fixed by the time you click on the link, I attach a current screenshot. Click on the image to look at the title and see what amused me.

Either way I think it's funny. No, it doesn't take a lot to amuse me. I guess I'm just a geek at heart.

Stani Wins Coin Design Competition

If you subscribe to the Planet Python feed you will already know that Stani (this is to the best of my knowledge the only name he advertises), the author of the well-known Stani's Python Editor, just won a competition to design a new Dutch five-Euro coin.

Congratulations, Stani, and not just for an exceptionally creative use of open source software (including Python, naturally), but also for a fine demonstration of its ideals. What a pity you can't release the coin under a copyleft agreement!

It seems to me this is just another area where the demonstrable abilities of open source are only just beginning to make an impression. You ain't seen nothing yet!

Norton Antivirus 2009 on Vista is a Liabilty

Today, for the second time in less than two weeks, the first attempt to collect mail after a reboot cause the appearance of a rather unpleasant notification dialog indicating that my Antivirus software has stopped working:

The first time this issue occurred I spent almost four hours online with the Symantec support technicians, having my software removed and re-installed several times without any resolution of the issue. At that point I had to go out, and when I returned the issue was somehow gone. I assumed that some component had been automatically updated, and continued on my merry way.

Today, we went through the same remove/re-install rigmarole with no more success. After the technician (who was controlling my computer remotely) went quiet for three or four minutes, then he closed the browser windows and disconnected the support session. Thanks very much.

The really annoying thing is that this is a known issue that Symantec claim will "be fixed in the next support upgrade", but there is no information about when this upgrade will happen, and neither does there appear to be a workaround I can apply until the fix appears, short of falling back to Norton Antivirus 2008. So I suppose that's what I'll have to do.

I'm guessing there are a lot of other people experiencing the same issue, because I started out as eighteenth in line for support. I am now next, and looking forward to going back to the prior release. But that was installed by a Symantec technician in response to a long-forgotten problem with the 2008 product, so I may not be out of the woods even then. If Symantec think I'm renewing at the end of my current subscription period they have another think coming. I have already spent almost a full day without email twice because of this issue, and I've had enough.

For some reason a number of posts were stuck in the blog as drafts. This one is from October last year.

It's Here!

I may be an old fart, but I know when a 'phone is going to be cool. To think I was actually the guy who registered "gPhone.com" (for a client). It would be nice to see Steve McCarthy and Guy Jazynka get something for the name. They might even buy me a pint!

At least I get a chance to play with Chrome. So, who knows where the Python interpreter is?

Shame I am feeling so ropey, I'd have loved to spend the evening playing on the Intarweb. Maybe tomorrow I'll blog from the 'phone.

Django Tip: Non-editable Fields

Yesterday I explained how to subclass a DateTimeField, adding a pre_save() method to make it suitable for use as a row creation or modification timestamp. If you do this, however, you will observe that unless you add an editable=False argument to the field instantiation call they will appear as editable fields in any ModelForms containing them. It would clearly be more desirable to have these fields non-editable by default, which can easily be arranged by extending their __init__() method and changing the default value of the editable argument.

The code below also renames the fields more suitably. You can use a similar trick to create other non-editable field types, and also to change other instantiation defaults.

class ModificationDateTimeField(models.DateTimeField):
  def __init__(self, editable=False, *args, **kw):
      models.DateTimeField.__init__(self, editable=editable, *args, **kw)
  def pre_save(self, instance, add):
      val = datetime.datetime.now()
      setattr(instance, self.attname, val)
      return val

class CreationDateTimeField(ModificationDateTimeField):
  def __init__(self, editable=False, *args, **kw):
      models.DateTimeField.__init__(self, editable=editable, *args, **kw)
  def pre_save(self, instance, add):
      if not add:
          return getattr(instance, self.attname)
      return ModificationDateTimeField.pre_save(self, instance, add)

Django Tip: Field.pre_save()

Here's a little thing that can help you to improve the flexibility of your models.

Rather than trying to extend or override Model.save(), if the special action you require only affects one field then define a subclass of the required Field type and define a pre_save() method on the subclass. This will override the default method, which simply returns the attribute value.

I spotted this by following up a discussion of the planned removal of the DateField's auto_now and auto_now_add attributes, which you can assert to set a modification or creation date respectively on rows. Some developers suggested putting the functionality in a decorator that could be used on the model's save() method, but Jacob Kaplan-Moss preferred a trivial subclass:

class AutoDateTimeField(models.DateTimeField):
def pre_save(self, model_instance, add):
    return datetime.datetime.now()

Unfortunately this is just a little bit too trivial, since pre_save() is required to set the attribute value - every time for auto_now and on first save for auto_now_add. Fortunately the extra code required is pretty small. pre_save() receives three arguments: the first is the field instance, the second is the model instance and the third is a flag which is True only when the save() call is adding a new row to the associated table.

class AutoNowDateTimeField(models.DateTimeField):
  def pre_save(self, instance, add):
      val = datetime.datetime.now()
      setattr(instance, self.attname, val)
      return val

class AutoNowAddDateTimeField(AutoNowDateTimeField):
  def pre_save(self, instance, add):
      if not add:
          return getattr(instance, self.attname)
      return AutoNowDateTimeField.pre_save(self, instance, add)

Technically it would be cleaner to use super() to access the superclass methods from AutoNowAddDateTimeField, but as a proof of concept this works fine.

As it happens the auto_now and auto_now_add attributes of DateTimeField were not removed before the release of Django 1.0, so we are likely to be stuck with them until 2.0. But the same technique is useful for any field that needs to receive an automatic value when a model instance is saved.

Python 2.6 Released

Thanks to release manager Barry Warsaw and a cast of thousands! Get it from the usual place.