Args parser about ponyge2 HOT 14 CLOSED

A comparison of several options: https://realpython.com/blog/python/comparing-python-command-line-parsing-libraries-argparse-docopt-click/

Brief HN discussion: https://news.ycombinator.com/item?id=10185290

Argparse (Python 3 docs): https://docs.python.org/3.7/library/argparse.html

Other options:

• Click http://click.pocoo.org/5/
• Docopt http://docopt.org

All of these would do a slightly better job of parsing our args, but they don't deal with the defaults + config file + command line args for us.

from ponyge2.

Stefan has accidentally committed a working version of a cleaner argument parser to the full default branch. You can check it out if you want to see how it works. Opinions/suggestions welcome!

from ponyge2.

Args parser is now formatted nicely and working correctly. Check it out at your leisure, we can discuss on Monday.

from ponyge2.

I think we used to have a check for non-existent command line options, but we don't anymore:

python ponyge.py --elephant

Start:	 2016-11-29 12:55:22.458737
(It runs happily!)

from ponyge2.

This is listed as a TODO. We parse non-existent command line options, we just don't do anything with them at the moment. The question is what do we want to do with them.

from ponyge2.

Check the first TODO in algorithm.parameters.set_params()

from ponyge2.

from ponyge2.

@dvpfagan shouldn't the same logic apply to the params file? If you haven't defined it in the dict/code, you should not be able to use it.

Either extra params in the param file and command line can be defined or no extra params can be defined at all.

from ponyge2.

from ponyge2.

I'm leaning towards Stefan's point of view. If we allow people to add new key:value pairs to the params dictionary from a params file, why not from the command line too? If they make spelling mistakes and mess things up, then surely it's their fault. I don't think it's our responsibility to put preventative measures in place for such an event.

from ponyge2.

I don't mind too much which way it goes.

But if we aren't going to throw an error, we can still warn the user to catch spelling mistakes. Since ponyge.py is quite verbose (e.g. the warning about unit codons) we could print a warning to say "Options --elephant unrecognised by PonyGE2 parser; may be recognised by user code."

This would be a usability win as I found out this afternoon when passing --search-loop instead of --search_loop about 10 times in a row.

(BTW --search-loop is more common, see e.g. man curl.)

from ponyge2.

Sounds like a good compromise that fits with the rest of the PonyGE implementation.

from ponyge2.

Decision: let's crash on mis-spelled args. User can use --extra_fitness_parameters for the fitness function. Otherwise new parameters they have to be added to the code.

from ponyge2.

Fixed 9d66639..cb64e8c

from ponyge2.