Menu

#8 Option default values not subject to type conversion

closed-fixed
None
5
2004-06-02
2004-05-18
Greg Ward
No

Optik assumes that option default values are what the
programmer wants out of the option parser, not what the
user puts in. That's fine for all the built-in types,
where input and output are closely and obviously
related. (Eg. input "foo" is output "foo", input "37"
is output 37.)

But this breaks down when developers define custom types:
* if str(input) != str(output), then default values
don't look
very good if included in help output
* if the developer is thinking in input terms (eg.
the string "5m"
rather than the int 300), it's extra cognitive
load to set default
values appropriately

I'll attach an example provided by John Belmonte that
illustrates the problem nicely. I suspect the fix is
to subject default values to the same type-checking and
-conversion routine as user-supplied values, but
haven't thought through the consequences of such a
change yet.

Discussion

  • Greg Ward

    Greg Ward - 2004-05-18

    examples/custom_type.py: illustrates problem with custom type and default value

     
  • John Belmonte

    John Belmonte - 2004-05-18

    Logged In: YES
    user_id=282299

    In my original message about this, I suggested adding a new keyword, "nice_default", to Option and add_option to cover the new semantics. This would prevent breaking existing code that uses custom options with defaults.

    You replied that it may be better to just use the existing "default" keyword, but have option checkers (possibly) support already cooked values as input. I think there are problems with that, because it places an unnecessary burden on the option checking function. Furthermore, for some transformations (e.g., str -> str), there may be no way to tell if a value has already been cooked. In any case, if you change the semantics of "default", backwards compatibility will be lost, since existing custom options are not written to handle cooked values.

     
  • Greg Ward

    Greg Ward - 2004-06-02
    • status: open --> closed-fixed
     
  • Greg Ward

    Greg Ward - 2004-06-02

    Logged In: YES
    user_id=14422

    Fixed by changing OptionParser.get_default_values() as
    described above. One wrinkle: it's possible to revert to
    1.4.1 behaviour by calling
    parser.set_process_default_values(False).

    Implemented in:
    lib/option.py rev 1.28
    lib/option_parser.py rev 1.60
    Tested in:
    test/test_optik.py rev 1.26

     

Log in to post a comment.