challenge_23 : about temperature_conversion

[MPKenley]

---

name: solution review temperature_conversion
about: A template PR for code review with a checklist

Behavior

The program should accept a list of temperatures in Celsius as input.

It should output a list of corresponding temperatures converted to Fahrenheit.

The conversion should follow the formula: 𝐹 = (9 / 5 ) C + 32

The program should handle positive, negative, and zero temperatures correctly.

It should also correctly process an empty list by returning an empty list.

The program should handle floating point numbers accurately.

Any invalid input (such as None, strings, or dictionaries) should raise an appropriate error.

Files

• The file name describes the function's behavior
• There is a module docstring in the function file
• The test file's name matches the function file name -
  /tests/test_file_name.py
• There is a module docstring in the tests file

Unit Tests

• The test class has a helpful name in PascalCase
• The test class has a docstring
• Every unit test has
  • A helpful name
  • A clear docstring
  • Only one assertion
  • There is no logic in the unit test
• All tests pass
• There are tests for defensive assertions
• There are tests for boundary cases

Function Docstring

• The function's behavior is described
• The function's arguments are described:
  • Type
  • Purpose
  • Other assumptions (eg. if it's a number, what's the expected range?)
• The return value is described
  • Type
  • Other assumptions are documented
• The defensive assertions are documented using Raises:
  • Each assumption about an argument is checked with an assertion
  • Each assertion checks for only one assumption about the argument
• Include 3 or more (passing!) doctests

The Function

• The function's name describes it's behavior
• The function's name matches the file name
• The function has correct type annotations
• The function is not called in the function file

Strategy

Do's

• Variable names help to understand the strategy
• Any comments are clear and describe the strategy
• Lines of code are spaced to help show different stages of the strategy

Don'ts

• The function's strategy is not described in the documentation
• Comments explain the strategy, not the implementation
• The function does not have more comments than code
  • If it does, consider finding a new strategy or a simpler implementation

Implementation

• The code passes the formatting checks
• The code passes all Ruff linting checks
• The code has no (reasonable) Pylint errors
  • In code review, you can decide when fixing a Pylint error is helpful and
    when it's too restricting.
• Variables are named with snake_case
• Variable names are clear and helpful
• The code follows the strategy as simply as possible
• The implementation is as simple as possible given the strategy
• There are no commented lines of code
• There are no print statements anywhere
• The code includes defensive assertions
• Defensive assertions include as little logic as possible

[Lastrophysicien]

Error Handling: You raise ValueError with clear messages, which is great for users and debugging.
Code Simplicity: The code is easy to follow and doesn’t contain unnecessary complexity. Great job keeping things clean!

[Lastrophysicien]

Error Handling: You raise ValueError with clear messages, which is great for users and debugging.
Code Simplicity: The code is easy to follow and doesn’t contain unnecessary complexity. Great job keeping things clean!

[Lastrophysicien]

Docstring Clarity and Examples
Your docstring is very well-written, and the examples are useful. However, it can be made slightly more concise.
You should specify that the function works with a list of numerical values (either integers or floats), and mention that it rounds the results to 2 decimal places.
The phrase "invalid elements" in the Raises section could be clarified as "non-numeric elements".
Error Handling: You raise ValueError with clear messages, which is great for users and debugging.
Code Simplicity: The code is easy to follow and doesn’t contain unnecessary complexity. Great job keeping things clean!

[MPKenley]

Thanks for your suggested change Clifford. But for the invalid input i specify kind of it is. Because there's different type of invalid input.