This would be a good self-contained piece of work to pass off to somebody... want to detach a name from it and see if anybody else wants it? It's just everything has your name on it :)

Chris Heidt should post a demo here. We can hammer out the specification either after the demo or once we do the face to face.

How's this one going?

How's progress on this? Deadline was today...

I've made the corrections that you asked, so that much is done, I think. However, I've been trying to figure out how to write a unit test for something that takes command line arguments and I've been coming up blank. I tried playing with sys.argv as you recommended, but I wasn't able to write to it. You also suggested writing a script, but I do not know of a way to write a script to execute a command line, so I've run into a wall there as well. Doing a google search on unit testing argparse only turns up a trick someone used to get around the need for a command line input, rather than a proper unit test for the argparse function.

Anyway I'll upload my work tonight (in a few minutes) if you could take a look and comment on the formatting and content of the documentation I wrote, then I can get that cleaned up rather quickly.

You should have asked.

Can call a script using either

os.system

subprocess.popen

If you set sys.argv within the test, then call Configuration() it should see it.

import sys
sys.argv=['application_name', '--do-something']

Well, any stuff taken from command line will always be a string, so argparse is doing the right thing.

How do you handle the case where we want something with string type, but numerical value. Like what if we want something to have string value '15'? Suggest taking type from ConfigurationDefaults and try casting to this type... leave the exception if this fails, it means bad user input.

15 int('15')

15.0 float('15')

FYI

Similarly: str(15.0) == '15'

And I'd strongly recommend using argparse instead of reinventing the wheel

I checked the type associated with the ConfigurationDefaults and was able to fix the problem, though it only checks against the types we are currently using. Would it be possible to do something like:

if type(Default) != type(New):
type(New) = type(Default)

Also I don't think there is a way to change simulation_reference_particle's (which is a dict in itself) default value using this method.

That's fine - we can change primitive types on command line, changing anything more complex we can do as an upgrade.

I've pushed my revision to Configuration.py to my branch, as it stands right now it is good for entering int, float, str, and bool types. I was working on some recursion stuff to try and get at the dict type variable, but I think that will take some time and I wanted to get this up.

I've also added the ability to specify a file with the -card command, I know this isn't what you were looking for, but I figured it didn't hurt to throw that in as well. Besides using a datacard will give you the ability to work with dict types.

Revision 587 is the Configuration.py file
Revision 588 is the tests I wrote

But just to be explicit - please put a sensible error message in, even if it doesnt say anything (like "Function not implemented")

That's what goes in instead of 'hi'

ok, I've updated the code so that it prints out an error if the variable simulation_reference_particle differs from that stored in the Default Configuration file, which is currently our only dict type variable in the file. Error message reads:

Unable to modify variable simulation_reference_particle
The feature has not yet been implemented into code.

Then exits the back to the command line using sys.exit().

Should raise an exception. Exceptions can be handled if we want - or return to command line if we want also.

sys.exit() is a very aggressive way to deal with bad input.

Change sys.exit to raise NotImplementedError("bad input") and see what happens. It should exit and say why.

This should take priority over tracker code review (the tracker code is rejected till it compiles).

I'm looking here:

http://bazaar.launchpad.net/~cheid001/maus/devel/view/head:/src/common_py/Configuration.py

Delete 54-56 since it's too specific and this code is meant to be very general. The way of addressing that situation is by changing like 66 to:

raise NotImplementedError("Unable to parse complex types. See issue #461.")

You need to update lines 40 and 29-38 to explain what the function does with your changes. It would be nice to add some comments within the code to explain (to new people to the code) what you're trying to do with parsing the arguments. This will appear here:

http://micewww.pp.rl.ac.uk/embedded/maus/doxygen_framework/html/classcommon__py_1_1Configuration_1_1Configuration.html

when it's commited.

Can you run:

bzr merge lp:maus

to make sure you're in sync with the trunk? Makes it easier for us to include the fixes and make sure it doesn't break anything.

This is really cool! I'm running it and it's very useful! Nice!

When you run bin/simulate_mice.py do you get a weird error?

Tunnell - I do all of my code testing with ./simulate_mice, I get no errors, weird or otherwise when I run.

I'm pretty sure I'm all merged up as of right after my previous commit, I think this version of Configuration.py should incorporate everything you guys have done.

I caught an error with changing the boolean stuff which I have fixed. I changed how errors are handled for dict type arguments so that they would behave how you specified, in addition to that I've also written a lot of new exception handlers. The new changes will recognize when you do something silly like change sigmaPz = 5 to sigmaPz = bob and raise an exception, however, the program will no longer crash if you change sigmaPz to 5.25, it will simply change it from an int type to a float.

Finally, I added a lot of commenting everywhere (except for the new stuff at the end which I didn't look at).

Where did you put the regression tests? I couldn't see anything in tests/py_unit/test_core_configuration.py

Rogers edit: fix the file name to be meaningful

• pulled this into Rogers branch
• moved the command line stuff into a subfunction
• Added protection to stop command line argument parsing unless explicitly requested. This stops the whole thing breaking when it tries to parse the command line arguments from e.g. nosetests
• added regression tests
• fixed all so they pass pylint

Please see:
http://bazaar.launchpad.net/~chris-rogers/maus/devel/view/head:/src/common_py/Configuration.py
http://bazaar.launchpad.net/~chris-rogers/maus/devel/view/head:/tests/py_unit/test_configuration.py