Wandering Thoughts archives

2008-08-17

Thinking about the best way to handle command registration

Suppose that you have a Python utility program that does a number of related things; it's invoked as 'program command ....', and decides what to do based on what the command is. The obvious way to implement this in Python is to have a function for each command and a top-level dispatcher that looks up the function to call for each command and passes it the arguments to process. Clearly you don't want to hard-code this in the dispatcher function in a big if/elif block; instead you want to somehow register all the commands in a simpler, easier to maintain way.

Since I have been writing such a utility program, I have found myself wondering what the best way of doing this is (where 'best' means 'most natural, obvious, and easy to follow'). So far I've come up with a number of possible ways:

  • have a dictionary where the key is the command name and the value is a tuple of information about the command (including the function to call, the minimum and maximum number of command line arguments it takes, and some help text).

    (The obvious and simple approach, but it starts getting more and more awkward as you add more per-command data to keep track of. You can use a structure instead of a tuple, but then you are complicating the simple scheme.)

  • call a registration function to define a command, giving it all of the details:
    def cmdfunc(args, ...):
      <whatever>
    register('cmd', cmdfunc, ...)

    (The registration function can have defaults for various things.)

  • use a decorator function to do the registration:
    @register('cmd', ...)
    def cmdfunc(args, ...):
      <whatever>

  • attach all of the information to the function as function attributes, and have a simple scheme to relate the command to the function name. The top level dispatcher then uses introspection to find if the command exists and to pull out anything else it needs.

Naturally you can combine aspects of all of these together to create hybrid systems (for example, using the function's docstring for some of the user help text).

Of these, I suspect that the decorator function approach is the most Pythonic but is also the second hardest for people who are not experienced Python programmers to follow (introspection would probably be the hardest). Since that last issue is a consideration, I am leaning towards using the plain registration function approach.

(My current code mostly uses the simple dictionary approach, but it's not the clearest thing to follow.)

python/ConsideringCommandRegistration written at 23:38:03; Add Comment

Why your blog comments have less of an audience than new blog entries

Expanding on a remark in the previous entry: I think there are several reasons why your comments are likely to get less of an audience than new entries. First, in most blog setups new comments are less obvious to readers than new entries, as your readers have to go back by hand to look for them. This is especially so if people are only interested in a few comments.

It's possible to work around this with a different blog layout, but it does mean a moderately radical change from how people think of blog front pages and so on. I suspect that it would work better for a blog that already mingles quick links with regular articles, and I think you would want to promote only some of your comments this way, because many quick comment replies require too much context.

Second, I think that many comments are intrinsically less interesting than a new entry, because they are effectively expanding on some aspect of your original entry. They are thus for people who are so interested in the topic that they want even more, and not as interesting to people who were satisfied with your original entry in the first place. This isn't always the case, but to the extent that your comment replies are of general interest, you might as well make them full entries.

(And some comment replies are only going to be interesting to people who read the comment that you're replying to, since they're just correcting or reacting to those comments instead of expanding on your original entry.)

web/WhyCommentsLessAudience written at 01:59:18; Add Comment

Another reason to avoid having comments

To go with my previous thoughts about the purposes of comments, here is another reason that people might want to not have them on their blog: they eat your limited time.

In a sense, comments on your blog carry with them an implicit duty to reply; while you can skip this, it may look odd and cause bad reactions. However, comments that you write will probably get less of an audience than a new entry. So if you only have a limited amount of time to write things for your blog, your time is better spent not having comments and just writing entries.

How true this is depends on how much of your time writing comments takes up. While many comment replies can be written quickly, I think that sooner or later you do run into comments that need about as much work as an entry. Sometimes those can be turned into actual entries (I do this a fair bit, although that's partly an interface issue), but not always; sooner or later you'll get comments that need replies that are too specialized or not interesting enough to make decent entries.

(This also ignores the time required to moderate comments, getting rid of spam and other undesirable things. Depending on the nature of your blog, this may be a significant time sink itself.)

web/CommentTimeUsage written at 01:54:17; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.