[RFC] Optparse option handling

Adeodato Simó dato at net.com.org.es
Thu Aug 10 20:09:03 BST 2006


* John Arbash Meinel [Tue, 08 Aug 2006 15:45:34 -0500]:

> 2) Ability to add new items. Depending on how it is done, this is
> easier/harder. Briefly looking over your code, it seems harder to have a
> plugin provide a new format, and have that be exposed on the command
> line. Because you have hard-coded the possible option in the EnumOption.
> I don't know how hard it would be to read it from some other list, which
> a plugin could keep updated.

> But especially for stuff like --log-format, where there is already a
> plugin or two that provides a custom log formatter.

I second this comment. Ideally, there would be a mechanism for them to
provide a short description, to print in the help output. For example, I
still hadn't look into implementing, but I was hoping for:

  def register_commit_template(name, function, editable=False):

      :param function: A function accepting (working_tree, specific_files,
          to_file) as arguments. If present, its __doc__ will be shown in
          'bzr commit --template help'.

Maybe... uhm.  John, I was going to reply to your LazyFactory message,
asking whether it could be morphed into a more general tool for
registering a name to a function/module.object/instance/whatever. This
way, there could be a new type of option, say FactoryOption:

  Option.OPTIONS['log-format'] = FactoryOption(LogFormatFactory)

And FactoryOption would do, for the default help:

  --log-format        factory.get_docstring() + 'Possible values are: %s.' %
                              ', '.join(factory.keys())

And for --log-format help:

  for k in factory.keys():
    print "%s: %s" % (k, factory.get_docstring(k))

Personally, I think this is a sensible proposal, both for having John's
LazyFactory more generalized (*), and not having EnumOptions, but
FactoryOptions instead.

  (*) Obviously, the functionality John specifically wants, about
      importing modules only when needed, would be provided by a
      subclass of the general FactoryRegistry (or however it's called).

Cheers,
  
-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
We learned that the Linux load average rolls over at 1024. And we
actually found this out empirically.
                -- H. Peter Anvin from kernel.org





More information about the bazaar mailing list