Monthly Archives: March 2009

Instead of setting instance attributes within __init__

I want to make sure that instances of my class have a bunch of attributes. This is the way I’ve always done it in the past:


>>> class C(object):
...     def __init__(self):
...         self.a = 1
...         self.b = 2
... 

It gets the job done fine. But when there’s real work to be done in __init__, then I end up with a really long __init__ method with essentially two separate goals. One section does interesting stuff with the parameters passed in, and the other section creates a bunch of attributes.

So now I’m experimenting with setting properties up for my classes like this:


>>> class D(object):
...     @property
...     def a(self):
...         if not hasattr(self, 'a'):
...             self.a  =1
...         return self.a

I like how I’ve moved the instance variables out of __init__, so that my __init__ method can focus entirely on handling the parameters. I’m curious what problems I’m going to have. At first, I thought I would trigger some infinite loop by accessing self.a when inside the property for a, but so far, I haven’t had any problems.

So what is wrong with this approach?

RIP Natchie

We adopted her in 2001 when Lindsey and I lived in Washington DC. Before that, Natchie lived with an economist I worked with, and I used to take care of Natch and another cat and a golden retriever occasionally.

I still remember one time when Lindsey and I were watching TV while I was pet-sitting. Natchie walked by the TV, looked at us, meowed, and then kept on walking. Was really endearing.

Natch loved affection more than any cat I’ve known. She would softly head-butt people to get them to pet her. She would hassle other animals to pet her. She loved to curl up next to the golden retriever and he would lick her.

Natch got her name from an Ethiopian phrase “Letenatchie!” That’s a drinking toast. Natch was an Absynnian, and the breed was supposedly from the area that is now known as Ethiopia.

It’s a gloomy day at the Wilson house today. We’ll miss her.

How to load ditz issues into python

Ditz is a fantastic distributed bug tracking system written in Ruby.

Here’s some code that you can use to load some ditz issues into a python interpreter. You need to install my pitz project first though.


>>> from pitz.junkyard.ditzloader import *
>>> from glob import glob
>>> issue_file_path = glob('../.ditz/issue-*.yaml')[0]
>>> import yaml
>>> issue = yaml.load(open(issue_file_path))
>>> issue.title
'Distribute reports by email'
>>> print issue.desc
Somehow allow people to sign up for report subscriptions.


So when new reports come out, they get updated.  Maybe I can use
<b>RSS</b> feeds to hold the reports.
>>> print issue.log_events
[[datetime.datetime(2008, 9, 2, 17, 47, 44, 549355), 'Matthew Wilson <mw@staffknex.com>', 'created', ''], [datetime.datetime(2008, 9, 2, 19, 18, 3, 286902), 'Matthew Wilson <mw@staffknex.com>', 'assigned to release 3.5.1 from unassigned', ''], [datetime.datetime(2008, 9, 4, 18, 27, 19, 571991), 'Matthew Wilson <mw@staffknex.com>', 'unassigned from release 3.5.1', '']]

That above just showed how to read the ditz issue. I’m having trouble updating the issue and then saving it in a format that ditz can still read. Updating the ditz issue and saving it out again is easy:


>>> issue.title = 'Distribute reports by email or RSS'
>>> open(issue_file_path, 'w').write(yaml.dump(issue))

But when I try to load it with ditz, I get this error:


$ ditz show 1209b
/home/matt/checkouts/ditz/lib/ditz/model-objects.rb:124:in `sort_by': comparison of String with Time failed (ArgumentError)
        from /home/matt/checkouts/ditz/lib/ditz/model-objects.rb:124:in `assign_issue_names!'
        from /home/matt/checkouts/ditz/lib/ditz/model-objects.rb:51:in `issues='
        from /home/matt/checkouts/ditz/lib/ditz/file-storage.rb:21:in `load'
        from /home/matt/checkouts/ditz/bin/ditz:165

I compared my dumped file to the original ruby file and found that python wrote dates out like this:


>>> print yaml.dump(issue.creation_time)
2008-09-02 17:47:43.268059

But in the ruby yaml files, the dates look like this:


$ grep creation_time ../../../.ditz/issue-1209b17b64335383a710ccadf10b74c3401dbcb2.yaml 
creation_time: 2008-09-02 17:47:43.268059 Z

That trailing Z seems important.

Also, python and ruby seem to write out lists differently. Here’s how python dumped a list of lists:


>>> print yaml.dump(issue.log_events)
- [!!timestamp '2008-09-02 17:47:44.549355', Matthew Wilson <mw@staffknex.com>, created,
  '']
- [!!timestamp '2008-09-02 19:18:03.286902', Matthew Wilson <mw@staffknex.com>, assigned
    to release 3.5.1 from unassigned, '']
- [!!timestamp '2008-09-04 18:27:19.571991', Matthew Wilson <mw@staffknex.com>, unassigned
    from release 3.5.1, '']

But the same data dumped by ruby looks like:


log_events:
- - 2008-09-02 17:47:44.549355 Z
  - Matthew Wilson <mw@staffknex.com>
  - created
  - ""
- - 2008-09-02 19:18:03.286902 Z
  - Matthew Wilson <mw@staffknex.com>
  - assigned to release 3.5.1 from unassigned
  - ""
- - 2008-09-04 18:27:19.571991 Z
  - Matthew Wilson <mw@staffknex.com>
  - unassigned from release 3.5.1
  - ""

So, there’s clearly some more work for me (or you, this is an open-source project) to do.

Some progress on pitz

Pitz is my open-source, distributed, plain-text, command-line, very flexible issue tracker. I just started working on it and I’m looking for feedback and contributors.

This post describes a little of what I’ve gotten done so far. I haven’t written any interface yet other than from within an interactive python session. Deal with it.

Getting started

You have to make a bag to keep all the tasks and then you make tasks with any keywords you can dream up.


>>> from pitz import Bag, Task
>>> b = Bag('.pitz')
>>> b.append(Task(title='Wash the dishes', creator='Matt', importance='Not very'))
>>> b.append(Task(title='Clean the cat box', creator='Matt', importance='Not very'))

You can add tasks to the bag by using the append method on the bag, or by passing in the bag as the first argument to the task:


>>> Task(b, title='Set new high score on Sushi-go-round', creator='Matt', importance='critical')

Printing a bag really prints the title of each task in the bag:


>>> print(b)
Clean the cat box
Set new high score on Sushi-go-round
Wash the dishes

Running queries

I’m proud of this one. This is the main reason I’m working on ditz. Bag instances have a feature called matching_pairs that can filter the tasks down to a smaller new bag.

You can filter by a single pair like this:


>>> critical_tasks = b.matching_pairs([('importance', 'critical')])
>>> print(critical_tasks)
Set new high score on Sushi-go-round

Or you can filter by multiple pairs and the filtered tasks must satisfy ALL the pairs.


>>> print(b.matching_pairs([('creator', 'Matt'), ('importance', 'Not very')]))
Clean the cat box
Wash the dishes

Dumping and loading

Use the bag that holds all the tasks to quickly write all the tasks out to your hard drive like this:


>>> b.to_yaml_files()
['.pitz/task-07e1af97-0ac6-4904-9187-0c2fd61692b6.yaml', '.pitz/task-6a7af07c-d0fb-4a77-9347-8dc78ef490fe.yaml', '.pitz/task-5ce725dc-c1db-4eca-a74c-55cd0e910786.yaml']

The returned stuff is a list of files that pitz just wrote.

Loading from the hard drive is pretty simple too. Just tell the bag where to load from.


>>> b2 = Bag('.pitz')
>>> print(b2)
Clean the cat box
Set new high score on Sushi-go-round
Wash the dishes

Task details

Printing a task by itself gives all the details on the task.


>>> t = Task.from_yaml_file ('.pitz/task-4d9c1db2-fef3-4b50-8095-b2339384e118.yaml')
>>> print(t)
Do the 2008 taxes
-----------------

            type: Task
            name: task-4d9c1db2-fef3-4b50-8095-b2339384e118
           title: Do the 2008 taxes
    created date: 2009-03-01 22:29:58.242512
   modified date: 2009-03-01 22:29:58.242512
         creator: Matt
last modified by: Matt

     description: 
Do the 2008 taxes

Other stuff

You can use bags as iterators to go through the tasks one-by-one:


for task in b:
    print(t['title'])

Also notice that tasks are really just subclassed dictionaries (UserDict, actually) with some extra methods bolted on.