[GRASS-dev] python parser question

[Glynn Clements]

Hamish wrote:

> the python version of m.proj in trunk now has:
> 
> #%option
> #% key: fs
> #% type: string
> #% description: Field separator (format: input,output)
> #% required : no
> #% key_desc : character,character
> #% answer : |,|
> #%end

You need "multiple: yes" in order to use key_desc this way (i.e. check
that answers are in the correct multiples). Otherwise, key_desc is
merely a string which is used in the help text, HTML/XML output, etc.

> Question:
> if the fs is a comma (.csv), won't that come to grief here:
>     #### parse field separator
>     ifs, ofs = fs.split(',')

Yes.

[With "multiple: yes", it will come to grief before that, in g.parser. 
If you have opt->multiple == YES, there is no way for an answer to
include a comma.]

> I find the current way to be too much typing. could it be like
> #% answer : input_fs[,output_fs]
> 
> so most of the time you don't need a,b? (if b==NULL then b=a)
> 
> (AFAIR the parser does special "2 input options required" checks
> if you use opt->key_desc="a,b")

Only for "multiple" options.

> or is fs_in= and fs_out= needed to please both the parser and the python?

Nothing stops you having fs=<string>, but nothing will check the
format of the string; e.g. the GUI won't stop you doing fs=a,b,c,d.

> or do we need a new
>     elif ifs.lower() == "comma":
> (I'd rather avoid that)

Yes. Well, if you're going to use a comma to separate the input and
output separators, you need to provide some way to specify a literal
comma.

-- 
Glynn Clements <glynn at gclements.plus.com>