pymc
pymc copied to clipboard
Updated pymc.simulator docstring (typos, defaults, type description)
What is this PR about?
fixing a number of issues with the pymc.simulator docstring.
...
Checklist
- [ ] Explain important implementation details 👆
- [ ] Make sure that the pre-commit linting/style checks pass.
- [ ] Link relevant issues (preferably in nice commit messages)
- [ ] Are the changes covered by tests and docstrings?
- [ ] Fill out the short summary sections 👇
Major / Breaking Changes
- ...
Bugfixes / New features
- ...
Docs / Maintenance
- ... added defaults to each parameter, changed instances of Aesara Op to correct format Aesara_Op, fixed a typo
Codecov Report
Merging #6035 (fb72b2e) into main (a8279d7) will decrease coverage by
0.00%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## main #6035 +/- ##
==========================================
- Coverage 89.30% 89.29% -0.01%
==========================================
Files 72 72
Lines 12890 12890
==========================================
- Hits 11511 11510 -1
- Misses 1379 1380 +1
Impacted Files | Coverage Δ | |
---|---|---|
pymc/distributions/simulator.py | 87.50% <100.00%> (ø) |
|
pymc/distributions/continuous.py | 97.47% <0.00%> (-0.43%) |
:arrow_down: |
pymc/distributions/multivariate.py | 92.00% <0.00%> (-0.03%) |
:arrow_down: |
pymc/func_utils.py | 88.37% <0.00%> (+0.87%) |
:arrow_up: |
pymc/parallel_sampling.py | 86.79% <0.00%> (+0.99%) |
:arrow_up: |
Hi Oriol, thanks for the feedback - these suggestions are really helpful. I'm a bit unsure about the procedure. To revise a pull request, do I make the changes on my branch and then resubmit the whole PR through the git command line instructions or is there a different procedure?
Make the changes locally and commit them to the branch you opened your PR from, docstring_update
in this case. After that you only need to push the changes and this same PR will be updated automatically with the new commits.
This is the last section in https://pymc-data-umbrella.xyz/en/latest/sprint/tutorials/pr_tutorial.html#get-ready-for-reviews which has the specific commands and extends the overview I gave in the above paragraph.
I implemented the suggested changes and then pushed them.
Also, one thing came up that wasn't strictly a docstring fix. I noticed the file uses inconsistent spellings of Kullback-Leiber and the class is incorrectly called KullbackLiebler. I thought we might want to change all of them to the correct spelling. I searched through the rest of the pymc package and couldn't find any references to the incorrectly spelled class, so I don't think this should cause trouble for other functions. But I'm also happy to ignore this and just stick to docstrings for now.
@daniel-saunders-phil I think it's ok to fix the spelling of Kullback-Leiber. I've been fixing spelling in the notebooks I have been updating, and it's been ok.
I’m not sure how to handle this pre-commit problem. I’m gonna try to figure it out for a little bit but I might have some questions in a couple of days.
@daniel-saunders-phil I am working on my 3rd notebook and, once again(!), stuck at the pre-commit stage. (+ possible git issue)
@OriolAbril Perhaps we should have a special office hours session on how to get through pre-commit. ;)
cc: @symeneses
@daniel-saunders-phil if you click on the "Details" button of the checks seciton you'll be able to see the checks logs. In this PR, the issue is with the "trim trailing whitespace": https://github.com/pymc-devs/pymc/runs/7715083643?check_suite_focus=true#step:4:64.
That means that there are lines that end up with a white character instead of finishing with the last letter/punctiation sign of the line. If you have followed the steps from https://pymc-data-umbrella.xyz/en/latest/sprint/tutorials/environment_setup.html to set up your environment, you can run pre-commit run --all
on your command line (while inside the pymc-dev environment). pre-commit will fail, but it will also modify the files and remove those trailing whitespaces. You can then git add and git commit those changes and push, which should fix the CI here.
It looks like all tests are passing this time! after a little bit of tinkering, I managed to get pre-commit working. Thanks a lot, @OriolAbril and @reshamas !
I considered it too but but eventually decided on not doing it because 1) it is not included in our docs and therefore not part of the public api and 2) no tests broke because it has not been refactored to v4, so it would be a breaking change on the private api with a major change version, from 3.11 to 4.x (whatever the version it gets updated).
We can still add the alias to be nice, but then it should have a different type of warning. This is the description of deprecationwarning in https://docs.python.org/3/library/exceptions.html#DeprecationWarning :
Base class for warnings about deprecated features when those warnings are intended for other Python developers.
Ignored by the default warning filters, except in the main module (PEP 565). Enabling the Python Development Mode shows this warning.
Congrats @daniel-saunders-phil !
#DataUmbrellaPyMCSprint