Hello @StanczakDominik! Thanks for updating your pull request.

• In the file plasmapy/formulary/dispersionfunction.py:

Line 162:18: W292 no newline at end of file

• In the file plasmapy/formulary/mathematics.py:

Line 18:1: E302 expected 2 blank lines, found 1

• In the file plasmapy/formulary/tests/test_dispersion.py:

Line 8:100: E501 line too long (102 > 99 characters)

• In the file plasmapy/formulary/tests/test_transport.py:

Line 16:43: E124 closing bracket does not match visual indentation

Comment last updated at 2019-10-17 08:31:28 UTC

Codecov Report

Merging #692 into master will decrease coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #692      +/-   ##
==========================================
- Coverage   95.04%   95.04%   -0.01%     
==========================================
  Files          59       57       -2     
  Lines        4707     4704       -3     
==========================================
- Hits         4474     4471       -3     
  Misses        233      233

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8f7f2c5...53fb10b. Read the comment docs.

I just realized, we're going to have to update a lot of things in the docs, aren't we?

Another thought is that it would probably be more straightforward for plasmapy.formulary to be imported automatically when doing import plasmapy, rather than having to specifically do import plasmapy.formulary or from plasmapy import formulary. This will probably be our most commonly used subpackage, and the first one that many people would go to.

Thanks for doing this!

Sure, can do!

I also wanted to discuss the API here. I rather dislike having to do from plasmapy.formulary.physics.parameters import a_thing; I'm thinking of getting rid of the pretty arbitrary separation between physics, mathematics and transport, and just putting all of that into the main formulary namespace. Flat is better than nested etc etc.

Yeah, allowing users to do something like from plasmapy.formulary import * and just have everything right there would be a real convenience for when they're interactively analyzing some data set. I like it!

Another thought...probably plasmapy.formulary is going to be one of the first packages to need a stable API (probably along with plasmapy.atomic). That is to say, it should soon become open for extension but not for modification. Probably version 0.3 will be too soon to promise that, but maybe 0.4 or 0.5.

Stable-ish - I think once we move stuff to formulary and do a cross-check with The Formulary itself to see what's missing, it'll be fine.

I'll try to finish the docs (again...) tomorrow.

Well, I may have gone a little overboard on the common namespace thing. See https://3007-46810954-gh.circle-artifacts.com/0/root/project/docs/_build/html/formulary/index.html. I think:

• I gave the page an auto-generated summary, but it's trying to look for definitions in the formulary/__init__.py file (due to star imports) and failing, so links aren't generating. I guess we could keep the per-topic summaries and say it's all available via plasmapy.formulary.alfven_speed.

• magnetostatics elements either need a separate place besides the formulary or shouldn't be *-imported into the

• I guess the only reasonable approach here is nuking the central autosummary - I'll do that.

By the way, I'm doing the star imports because we're defining __all__ in the modules, so it should be fine.

If this goes as expected, it should be ready for a round of review! (probably don't go by files, though!)