Restore unmodified code in parameters cell

[takluyver]

This uses ast.unparse() on Python 3.9, and the astunparse backport on older versions, to recreate any code in the parameters cell not recognised as parameter definitions.

The AST doesn't preserve comments or formatting, so these will be lost, but the code should still do the same thing. Any code that's not treated as parameters will be moved after the parameter definitions, which might change its behaviour in some rare cases, but hopefully not many.

While I was working on this, I also enabled:

• Recognising annotated assignments (a: int = 7) as parameters. The annotation is ignored for now - this is just like a = 7.
• Work with a dict of parameters by name, rather than a list. More convenient for checking e.g. 'does parameter x exist'.

Closes #17.

cc @philsmt - we had a discussion about this.

[codecov]

Codecov Report

Base: 92.08% // Head: 93.54% // Increases project coverage by +1.46% 🎉

Coverage data is based on head (344e537) compared to base (572dad0).
Patch coverage: 97.10% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #19      +/-   ##
==========================================
+ Coverage   92.08%   93.54%   +1.46%     
==========================================
  Files           3        3              
  Lines         139      186      +47     
==========================================
+ Hits          128      174      +46     
- Misses         11       12       +1     

Impacted Files	Coverage Δ
nbparameterise/code.py	93.50% <92.59%> (-1.24%)	⬇️
nbparameterise/code_drivers/python.py	93.45% <100.00%> (+3.45%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[takluyver]

Thinking some more about it, I realised that it would be easy enough to keep the recreated code in its original order, replacing each assignment in place. However, that highlights a couple of corner cases that so far haven't had much thought:

1. If the same name is defined more than once (a = 1; a = 2) and we want to set a to 3, do we replace both? Only the last one? Or should it be an error when extracting parameters? At present, the list-based APIs will extract two separate parameters with name 'a', and parameter_values() will change the value of both of them.
2. Is it OK to add parameters for names which aren't in the notebook to start with? At present, replace_definitions() is fine with this, but parameter_values() will silently ignore any names which don't correspond to an existing parameter (a behaviour which is definitely wrong).

🤔

[takluyver]

From Python 3.8, we could possibly even do something cleverer, using the character positions of the nodes to replace just those pieces, leaving the rest of the code untouched. That would be cool, but it's not my priority today.

[sam2332]

Wow this looks great

[takluyver]

I've now gone for supporting Python 3.8+ only, and preserving the surrounding code when replacing assignments with new parameter values.

With regard to my questions from this comment:

1. Duplicate names will be allowed, and setting a new value will replace all of them. I hope this is a corner case rare enough that we don't need to do anything special for it.
2. Adding new parameter names will still work - the assignments will be added to the bottom of the parameter cell. parameter_values() still ignores new names by default - I realised we were actually relying on this at EuXFEL - but you can pass new='add' or new='error' to change this. You can also give the new values in a dict instead of keyword args - if you have a parameter called new, you'll need to use this.

And one that I didn't ask:

3. It will no longer be possible to delete assignments from the parameter cell. In 0.5, you can remove some of the parameters from the list you pass to replace_definitions(), and the new parameter cell won't have those assignments. With these changes, they'll keep whatever they were assigned before.

[takluyver]

OK, I'm fairly happy with this now. I'll probably merge it on Monday unless anyone spots a major problem before then. Then I'll get back to other pull requests - sorry it has taken so long.