python-novice-inflammation
python-novice-inflammation copied to clipboard
More exception handling, less assertions
Resolves #979.
This is a substantial re-write of the defensive programming lesson due to lots of feedback in recent years pointing out that exception handling is in many/most cases a better alternative to assertions.
The re-write proposed in this PR can be view at:
https://damienirving.github.io/python-novice-inflammation/10-defensive/index.html
This is now ready for review.
I've trimmed back the assertion content and added new content on exception handling (as was the brief for this PR). This means I've left the test driven development section essentially unchanged. If people feel that the lesson is now too long the most obvious place to shorten the lesson would be that section - the range_overlap
example is quite long. By writing five assertions and then putting them in a test_range_overlap
function we're also super close to doing what you'd need to do in order to run pytest (you'd just put each assertion in its own function and put those five functions in a script called test_range_overlap.py
), so we could also consider actually using a testing framework (i.e. pytest) rather than just mentioning they exist.
I have left a couple comments but would like to see @swcarpentry/curriculum-advisors review this pull request before it is merged.
(The CAC has not met for a few months, while they waited for a new secretary to join the group. Now that is done, I hope you will be able to get some feedback on this soon @DamienIrving.)
I'll add this topic to the agenda for our next meeting. :)
Existing relevant discussion "issue" in our repo: swcarpentry/curriculum-advisors#1
Hi @DamienIrving ,
Thank you for the pull requests. The curriculum advisors are split on this so we will close this request in the mean time to be open at a later time after migration to Workbench.
Hello @DamienIrving,
Thank you for your work on this. I am the lesson infrastructure developer and one of the impacts of the transition to The Workbench by May is that all open pull requests must be merged and the forks re-created (https://carpentries.github.io/workbench/faq.html#github-forks).
Because your contribution is substantial, if you are not interested in starting the re-submission from scratch, I can help you transition your work to use The Workbench so that, after May, you can re-contribute and build from where you left off.
Sincerely, Zhian
Hi @zkamvar,
If you could help me transition my work to use The Workbench so I can re-contribute that would be great. Where do I start?
Hi @DamienIrving,
Yes, I can certainly help! To be clear, we will not be able to get to this until April or May due to the transition, but here is how we would proceed:
First, we would bring your branch up-to-date with the changes that have already occurred (this may involve some conflict resolution)
The next steps depend on whether or not you want to keep the commits you made or if you are okay starting from where you left off as a single commit. In both scenarios the end result will be the same: your changes will be proposed as a pull request.
Option 1: start from a single commit (most expedient)
Starting from a single commit is much simpler because it only involves copying and pasting the files into a new branch after a transformation of the one markdown file.
Option 2: migrate your commits
This is more more difficult, but I believe it is possible. We might be able to merge the pre-transformation changes into your repository, run the transformation, and then create a patch file that we can use to make a branch from the main branch and then create a pull request from that. That being said, there are a lot of factors that could prevent us from actually performing this operation. I can make a copy of your fork on my account and do some tests to see how things will play out.
The reason for the differences is because the transformation involves effectively replaying the history of the lesson as if the styles infrastructure never existed (see the motivation section in the lesson-transition repository). Because of this replay, all of the commit hashes will change.
Apologies for the delay in responding, @zkamvar. Option 1 sounds good to me. How should we proceed with that option?