[PATCH]: Optional explanation for options

[John A Meinel]

Martin Pool wrote:
> Thanks for starting a discussion of this Magnus.  I think I'd like to
> have command objects say that they either take a standard option, or
> define their own options.
>
> so
>
>   takes_options = ['verbose',
>      Option('special', help='make this command more special'),
>      Option('niceness', paramtype=int)]
>
> If it's a string, it's looked up in the global options; otherwise it's
> an option object.
>
> Then the standard options will be
>
>   [Option('verbose', help='display more progress messages'),
>    ...]
>
> How's that?
> How's that?
>

Sounds like you and I were thinking the same thing. Or at least
something similar. I took one more step from you, to say that when the
user supplies an Option, it checks to see if there is a default option
with the same name, and pulls all the defaults from it.

It just changes how unspecified defaults are handled. You way would have
something like:

class Option(object):
    def __init__(name, help='', paramtype=None):
      self.name = name
      self.help = help
      self.paramtype = paramtype

Mine would be more like:

class Option(object):
    def __init__(name, help=None, paramtype=None):
      self.name = name
      if OPTIONS.has_key(name):
        opt = OPTIONS[name]
        if help is None:
          self.help = opt.help
        else:
          self.help = help
        if paramtype is None:
          self.paramtype = opt.paramtype
        else:
          self.paramtype = paramtype
      else:
        if help is None:
          self.help = '' #Default value for help
        else:
          self.help = help
        if paramtype is None:
          self.paramtype = None # Default value for paramtype
        else:
          self.paramtype = paramtype


Mine is more complex in form, but the point is for usage. For yours:

class my_command(Command):
  takes_options = ['verbose',
	Option('revision', paramtype=bzrlib.builtins._parse_revision,
               help='supply a range of revisions')

My version:
class my_command(Command):
  takes_options = ['verbose',
	Option('revision', help='supply a range of revisions')

Here it means that I don't need to know how to parse a 'revision'
string, as long as I use the globally defined method.

It depends a little on how many parameters an Option is going to have,
if it is just these 3, it isn't that onerous to require you to be explicit.

If you are going to have more than 3, you start having to worry about
more and more settings, which may already be defined globally.

On the flip side, if I ever did:

class my_2nd_command(Command):
  takes_options = [Option('an-option', help='enable some behavior')]

Both methods would default this to the None action, meaning it is a
boolean flag.
But if my name happens to collide with a future global name, all of a
sudden my plugin/command starts trying to treat it as taking a
parameter, which my command doesn't know how to handle.

I can see both sides, so I mostly wanted to raise it up for discussion.
(Right now I'm leaning to Martin's proposal, because it is more
explicit, so there is less chance of future surprise, and we really only
have 3 parameters anyway. If we had something like 5, I would be more
tempted to inherit from global definitions by default.)

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050912/72a7804c/attachment.pgp