Update 10-defensive.md

[dhvalden]

complete change of the lesson to cover exceptions and try except pattern. Closes #1084

If this pull request addresses an open issue on the repository, please add 'Closes #NN' below, where NN is the issue number.

Please briefly summarise the changes made in the pull request, and the reason(s) for making these changes.

Changes completely the lesson to cover input validation using exception and try except patterns. It addresses #1084 adn #979

If any relevant discussions have taken place elsewhere, please provide links to these.

#979 #622, #773 and #874,

For more guidance on how to contribute changes to a Carpentries project, please review the Contributing Guide and Code of Conduct.

Please keep in mind that lesson Maintainers are volunteers and it may be some time before they can respond to your contribution. Although not all contributions can be incorporated into the lesson materials, we appreciate your time and effort to improve the curriculum. If you have any questions about the lesson maintenance process or would like to volunteer your time as a contribution reviewer, please contact The Carpentries Team at [email protected].

[github-actions[bot]]

:ok: Pre-flight checks passed :smiley:

This pull request has been checked and contains no modified workflow files, spoofing, or invalid commits.

It should be safe to Approve and Run the workflows that need maintainer approval.

[martinosorb]

The first part can be read as using assert for input validation, which we have all agreed is not right, but could also be interpreted as testing, if we assume the input comes from other parts of our code. However, this is not sufficiently clear, and I agree to change this part to raising errors, since raise is not taught anywhere else.

The main problem is that we're throwing away the baby with the bathwater, as this becomes an episode on input validation only, removing the rest. I'd say we could keep a part on assert, and on the benefits of adding little testing devices to our code, which was the main point of this episode. We can also still briefly talk about TDD, but without all the current detail.

In summary, I would

• keep the current introduction that motivates testing and checks
• when talking about pre-conditions
  • introduce raise for input validation
  • add some of @dhvalden's new material motivating input testing.
  • the discussion on the difference between TypeError and ValueError should be moved to ep 9, where all the error types are discussed, but can be referred to in the example
  • alternatively, we can keep the current example, which both shows pre- and post-conditions, so I think is better suited
• when talking about post-conditions, introduce assert for quick testing and explain its benefits
• shorten the part on TDD
• introduce try...except, but with a real use case where there is no solution other than using it.

[quirksahern]

@dhvalden the SWC Lesson Program Governance Committee is keen to resolve the issue with this episode.

Are you willing to take on board @martinosorb 's comments and submit a revised pull request. For info both myself and Martino are members of the LPGC.

[dhvalden]

Hi!

Yes! I think I can address the comments and upload a revised version.

[ineelhere]

Please refer to PR https://github.com/swcarpentry/python-novice-inflammation/pull/1096 for an added suggestion on this topic. If this is not a potential conflict, PR https://github.com/swcarpentry/python-novice-inflammation/pull/1096 can be merged to lesson material.

[unode]

Thanks @ineelhere for the cross ref.

Just adding my two cents after skimming through the lesson proposed and the comments in this thread. Particularly in light of the recent experience teaching this chapter.

I agree with the sentiment above that the proposed changes shift the focus entirely to input validation. I believe it also opens up into aspects that are considered "philosophical" namely the correct or incorrect use of isinstance and when to create a custom exception versus raising or handling a built-in one. In the proposed example, should we 1. assume that it is a number and handle the error when it isn't or 2. ask if it is a number of a certain type (which excludes all numbers of other types).

The other philosophical aspect is the overall approach of "asking for forgiveness" vs "asking for permission". The best example I have in mind is "can I create a file?, please create" versus "create a file, oh sorry didn't know I couldn't". Arguably the latter is the better implementation because permissions could still change between asking and doing (or other racy situations) which would still lead to failure. So from a defensive programming point of view I believe we should focus on handling and anticipating the failure scenarios rather than double check out input assumptions. Our code would still be good code (better code?) if it can handle unexpected inputs but protects the user from nonsensical outputs.