Create info_functions.py

[bisogni]

"info_function.py" contains two functions, scan_info(num) and scan_dets(num), to retrieve easily information from a scan number 'num' within a notebook.

[awalter-bnl]

I have thought about it more and am no longer asking for test functions. I think the test functions would need to work on recently created data from bluesky, as the most likely error is a change to the format of the metadata. As I am not convinced this is possible I think this test should be added to a series of tests that instead are run at the beamline just before/after an blueksy/ophyd update occurs. (perhaps the six team wants to start collecting this set of tests together?)

I would still like to see this tested with flake8 to remove any of the style errors.

[ambarb]

ok @awalter-bnl is this flak8 in the tutorial stuff that was forwarded for the development tutorial you gave use at 2ID? The webpage with the style guide and stuff??

[mpmdean]

Hi @ambarb

The flake8 tool is imposing a set of style rules called PEP8 available here: https://www.python.org/dev/peps/pep-0008/

In general, I think it would make sense to be somewhat permissive of these sort of style issues with the provisos

• The function(s) in questions are somewhat separate in the sense that we don't need to build other stuff on top of the functions
• That we must develop sixtools towards a professional package that meets all these requirements. For example, we raise issues to provide these things in the future.

For the code in question, it's worth emphasizing that header._repr_html_() is intended to be returning what the user wants to read. Obviously, it doesn't, but I think keeping a similar approach might be the way to go long term.

Since we're severely underresourced for developing the code, my own preference would be to add a warning to the existing code and then merging it would be the way to go. I wouldn't want to get too deep into perfecting the style issues before thinking about the methods, but I am also keen to have everyone participating and being able to share their code.

[danielballan]

I'll offer my two cents about flake8 and style:

For context, many scientific Python projects strive to meet this standard but few are strict about it. It's most valuable for medium-to-large projects, where it can be useful to let a "robot" police style so that humans can focus their energy on arguing about more substantive things.

I strongly encourage you to strive to keep to it, but if you decide to remove it from .travis.yml so that a style infraction does not cause the builds to "fail", that would not be unreasonable.

[awalter-bnl]

I second @danielballan on this, implementing the a 'common' style makes reading/understanding the code easier for non-authors and helps significantly when multiple authors are working on it. I would strongly suggest that this be kept.

To answer @ambarb question, the use of flake8 is described in the tutorial here http://nsls-ii.github.io/scientific-python-cookiecutter/the-code-itself.html#lint-check-for-suspicious-looking-code