📝 Add docstrings to feat_patch

[coderabbitai]

Docstrings generation was requested by @laike9m.

• Support test_code to add pyright-config comment #98 (comment)

The following files were modified:

• tests/assets/challenges/basic-foo-pyright-config/question.py
• tests/conftest.py
• tests/test_identical.py
• views/challenge.py
• views/views.py

These files were kept as they were

• tests/test_challenge.py

These file types are not supported

• docs/Contribute.md

ℹ️ Note

CodeRabbit cannot perform edits on its own pull requests yet.

[coderabbitai]

Important

Review skipped

CodeRabbit bot authored PR detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[laike9m]

This Pull Request introduces significant improvements to the type-checking challenge system, primarily by enhancing how Pyright configurations are handled.

Here's a summary of the key changes and my review:

Key Changes:

1. Embedded Pyright Configuration: The PR introduces a mechanism to embed challenge-specific Pyright configuration directives directly within the question.py and solution.py files, separated by a ## End of test code ## marker. This allows for fine-grained control over type-checking rules for individual challenges.
2. PYRIGHT_BASIC_CONFIG: A comprehensive set of default Pyright configuration directives has been added (views/challenge.py), ensuring consistent and strict type-checking across all challenges unless overridden.
3. Refactored Test Code Extraction:
   • The test_identical.py test now correctly extracts only the actual test code (before the Pyright config marker) when comparing question.py and solution.py.
   • The get_challenge endpoint in views/views.py also truncates the displayed test code, preventing the embedded Pyright config from being shown to users.
4. Improved Pyright Error Reporting: The _type_check_with_pyright method in views/challenge.py now distinguishes between errors originating from user code, test code, and the embedded Pyright configuration. Errors in the Pyright configuration itself are no longer considered to be failures for passing the challenge.
5. Enhanced Code Readability and Maintainability:
   • Docstrings have been added or improved for several functions and fixtures, enhancing clarity.
   • The PYRIGHT_MESSAGE_REGEX now uses named capture groups, which is a good practice for regex maintainability.
   • The hint_file fixture and ALL_HINTS variable were removed from tests/conftest.py, simplifying the test setup for hints, which are now handled directly via the ChallengeManager.

Constructive Feedback:

• No Newline at End of File: I noticed that some of the modified files (e.g., tests/assets/challenges/basic-foo-pyright-config/question.py, tests/conftest.py, tests/test_identical.py, views/challenge.py, views/views.py) still lack a newline at the end of the file. While not critical for functionality, it's a common style preference and can sometimes cause issues with certain tools. This is a pre-existing issue, and it's fine if this PR doesn't address it, but it's something to keep in mind for future code quality improvements.

Conclusion:

This is a well-designed and executed PR. The changes significantly improve the functionality and flexibility of the type-checking challenge system. The separation of test code from Pyright configuration, the introduction of a base configuration, and the refined error reporting are all excellent additions. The improvements in documentation are also very welcome.

I'm approving this PR.

[laike9m]

test

[laike9m]

This Pull Request introduces significant improvements to how Pyright configuration is handled within the challenges, providing more flexibility and clearer error reporting.

Overall Impression:
The changes are well-structured and address a valid need to allow custom Pyright configurations per challenge, while maintaining a consistent baseline. The updated logic for error reporting is robust and correctly distinguishes between user/test code errors and configuration issues.

Key Improvements:

• Flexible Pyright Configuration: The introduction of PYRIGHT_BASIC_CONFIG and the _partition_test_code method in Challenge class allows challenge creators to embed specific Pyright directives within question.py (and presumably solution.py) files. This is a powerful feature for tailoring type-checking behavior to individual challenges.
• Improved Error Attribution: The _type_check_with_pyright method now intelligently adjusts line numbers for reported errors, ensuring they correctly map back to the user's code, the test code, or are identified as originating from the Pyright configuration block. This significantly enhances the debugging experience for users.
• Decoupled Config Errors from Challenge Success: The logic to not fail a challenge solely based on errors within the [pyright-config] block is a sensible design choice. It allows for valid configuration directives to be tested, even if they might contain minor syntax issues that don't directly impact the type-checking of the core challenge.
• Clearer Test Code Display: In views.py, only the relevant test code (before the ## End of test code ## marker) is displayed to the user, preventing clutter from configuration directives.
• Good Test test_identical Refactoring: The test_identical.py now correctly compares only the actual test code between the question and solution files, ignoring embedded Pyright configurations.
• Excellent Docstrings: New and modified fixtures (assets_dir, test_client, mgr) and functions (get_test_code, test_identical, _partition_test_code, _type_check_with_pyright, get_challenge) have clear and helpful docstrings, which greatly improves code readability and maintainability.

Minor Suggestions:

• tests/assets/challenges/basic-foo-pyright-config/question.py - Newline at EOF: It's generally good practice to end files with a newline character. The newly added question.py appears to be missing one. Please consider adding a newline at the end of this file for consistency and compatibility with various tools.

• Clarity of TypeCheckResult Message (Minor): In _type_check_with_pyright, when passed is True (meaning no functional errors in user/test code), error_lines might still contain [pyright-config] errors. The final message \nFound {len(error_lines)} errors could be slightly misleading in such cases. For instance, if there are only config errors and no actual type errors, it would be clearer to state "All tests passed (X errors in Pyright configuration)" or simply "All tests passed" if len(error_lines) is 0, and reserve "Found X errors" for actual failures. However, this is a minor readability improvement and doesn't affect the correctness of the passed flag.

# Current behavior:
# if passed is True (no non-config errors), but error_lines has config errors
# message will be "error_line_1\nerror_line_2\n... \nFound X errors"
# where X includes config errors.

# Suggestion (optional, for consideration in future refinements):
# if passed and all errors are config errors:
#    message = "\n".join(error_lines) + f"\nAll tests passed ({len(error_lines)} errors in Pyright configuration)"
# elif passed: # no errors at all
#    message = "\nAll tests passed"
# else: # not passed, there are functional errors
#    message = "\n".join(error_lines) + f"\nFound {len(error_lines)} errors"

Conclusion:
This is a well-implemented and valuable PR. The core changes are solid, well-documented, and improve the extensibility and user experience of the challenge platform.

I'm approving this PR, with the minor suggestions for consideration.

[laike9m]

This PR introduces significant and well-thought-out improvements to how Pyright configuration is handled within the challenges. The ability to embed Pyright directives directly into the question.py files provides much-needed flexibility for specific challenge scenarios.

Here's a breakdown of the changes and some constructive feedback:

Key Changes and Improvements:

1. Embedded Pyright Configuration: The introduction of the ## End of test code ## marker and the _partition_test_code method allows challenge authors to specify Pyright configurations on a per-challenge basis. This is a fantastic addition, enabling more nuanced type-checking challenges.
2. Default Pyright Configuration: The PYRIGHT_BASIC_CONFIG provides a solid baseline for type-checking, ensuring consistency across challenges while allowing for overrides.
3. Improved Error Reporting: The _type_check_with_pyright method has been refactored to correctly adjust line numbers for errors originating from user_code, test_code, and even the embedded pyright-config section. This significantly enhances the user experience by providing accurate error locations.
4. Ignoring Config Errors for Challenge Passing: The logic to disregard errors from the [pyright-config] section when determining if a challenge passes is a smart design choice. It prevents issues in the configuration itself from unfairly failing a user's correct solution.
5. Clean Separation in UI: The views/views.py update ensures that only the actual test code is displayed to the user, keeping the embedded Pyright configuration hidden from the challenge interface.
6. Refactored Test Code Comparison: The test_identical.py update correctly extracts only the test code part, ensuring that the embedded Pyright configuration does not interfere with the comparison between solution and question files.
7. Docstrings and Type Hints: The additions of docstrings and type hints in tests/conftest.py and views/views.py improve code readability and maintainability.

Minor Suggestions for Further Improvement (Non-blocking):

• Documentation for ## End of test code ##: Given the importance of the ## End of test code ## marker, consider adding a comment in _partition_test_code or a general README/contributing guide to explain its purpose and how challenge authors should use it. This will help maintainers and future contributors.
• Comments on PYRIGHT_BASIC_CONFIG: For clarity, you might add brief comments next to some of the pyright directives in PYRIGHT_BASIC_CONFIG to explain why they are set to a particular value (e.g., analyzeUnannotatedFunctions=true is often desired for type challenges).
• Error Message Origin Clarity: The error messages now correctly adjust line numbers. While [pyright-config] is clear, you could (optionally) make it explicit where the adjusted test code errors are coming from (e.g., test_code_line_X: error: ...) if you want to distinguish them even further from user_code errors, though the current adjustment is quite good.

Overall, this is a well-executed PR that significantly enhances the capabilities and user experience of the challenge platform.