wip: add pydantic support #1247
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
for more information, see https://pre-commit.ci
![recurseml[bot]](https://avatars.githubusercontent.com/in/1054195?s=60&v=4){kind=small}
| """Setup test app with advanced parameter routes.""" | ||
| app = Robyn(__file__) | ||
|
|
||
| # Test Query parameters |
There was a problem hiding this comment.
This comment is redundant as it's obvious from the code and route definitions that follow that these are query parameter tests. The code itself tells us what is being tested through the route paths and parameter types.
🔍 This comment matches your effective_comments.mdc rule.
| # Test Query parameters |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
| def query_alias(user_name: str = Query(..., alias="username")): | ||
| return {"user_name": user_name} | ||
|
|
||
| # Test Path parameters |
There was a problem hiding this comment.
This comment is redundant as the code that follows clearly shows through the route definitions and Path parameter usage that these are path parameter tests.
🔍 This comment matches your effective_comments.mdc rule.
| # Test Path parameters |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
| def path_typed(user_id: int = Path(...), score: float = Path(...)): | ||
| return {"user_id": user_id, "score": score} | ||
|
|
||
| # Test Header parameters |
There was a problem hiding this comment.
This comment is redundant as the subsequent code clearly demonstrates through the route definitions and Header parameter usage that these are header parameter tests.
🔍 This comment matches your effective_comments.mdc rule.
| # Test Header parameters |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
| "user_id": user_id | ||
| } | ||
|
|
||
| # Test mixed parameters |
There was a problem hiding this comment.
This comment is redundant as the code that follows clearly shows through the mixed use of Path, Query and Header parameters that this tests mixed parameter handling.
🔍 This comment matches your effective_comments.mdc rule.
| # Test mixed parameters |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
| def test_handler(name: str = Query(...)): | ||
| return {"name": name} | ||
|
|
||
| # Mock request |
There was a problem hiding this comment.
This comment is redundant as it's obvious from the MockRequest class definition that follows that this is creating a mock request object.
🔍 This comment matches your effective_comments.mdc rule.
| # Mock request |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
| from robyn import Robyn, Query, Path, Header | ||
|
|
||
|
|
||
| # Create the app |
There was a problem hiding this comment.
This comment is redundant and violates the effective comments rule as it merely restates what is obvious from the code app = Robyn(__file__) in the next line. The code is self-explanatory and doesn't need this comment.
🔍 This comment matches your effective_comments.mdc rule.
| # Create the app |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
| in_stock: bool = Query(True, description="Only in-stock items"), | ||
| categories: List[str] = Query([], description="Categories to filter by") | ||
| ): | ||
| """Search products with automatic type conversion.""" |
There was a problem hiding this comment.
This docstring is redundant as it merely restates what is already obvious from the function name 'search_products' and its type-annotated parameters. The docstring doesn't provide any additional context about why the function exists or important implementation details that aren't obvious from the code.
🔍 This comment matches your effective_comments.mdc rule.
| """Search products with automatic type conversion.""" |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
| # === 5. Mixed Parameters (All Types Together) === | ||
| @app.put("/items/:item_id") | ||
| def update_item( | ||
| user_data: CreateUserRequest, # Request body (JSON) |
There was a problem hiding this comment.
This inline comment is redundant as it's already clear from the type annotation that this is a JSON request body parameter. The type CreateUserRequest and its usage in a PUT endpoint makes it obvious that this is the request body.
🔍 This comment matches your effective_comments.mdc rule.
| user_data: CreateUserRequest, # Request body (JSON) | |
| user_data: CreateUserRequest, |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
|
|
||
| @app.post("/users") | ||
| def create_user(user: CreateUserRequest): | ||
| """Create user with Pydantic validation and automatic JSON parsing.""" |
There was a problem hiding this comment.
This docstring is redundant as the function name 'create_user' and the Pydantic model parameter already indicate that this endpoint creates a user with validation. The JSON parsing aspect is an implementation detail that's implicit in the framework's use of Pydantic.
🔍 This comment matches your effective_comments.mdc rule.
| """Create user with Pydantic validation and automatic JSON parsing.""" |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
| self.extra = extra | ||
|
|
||
|
|
||
| def _extract_parameter_info(param: inspect.Parameter) -> Dict[str, Any]: |
There was a problem hiding this comment.
The docstring following this function definition is redundant and should be removed. The docstring 'Extract parameter information including type annotations and advanced parameter metadata.' adds no additional value beyond what is already clearly stated by the descriptive function name and its type hints.
🔍 This comment matches your effective_comments.mdc rule.
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
|
|
||
|
|
||
| def _parse_query_params(query_params: QueryParams, param_info: Dict[str, Any]) -> Any: | ||
| """Parse query parameters with advanced Query objects.""" |
There was a problem hiding this comment.
The docstring is redundant and restates what is already clear from the function name '_parse_query_params'. The comment adds no additional context or explanation of complex logic that isn't already evident from the code itself.
🔍 This comment matches your effective_comments.mdc rule.
| """Parse query parameters with advanced Query objects.""" |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
|
|
||
|
|
||
| def _parse_path_params(path_params: PathParams, param_info: Dict[str, Any]) -> Any: | ||
| """Parse path parameters with advanced Path objects.""" |
There was a problem hiding this comment.
The docstring is redundant as it merely restates what is already clear from the function name '_parse_path_params'. The comment provides no additional insight or explanation beyond what the code itself conveys.
🔍 This comment matches your effective_comments.mdc rule.
| """Parse path parameters with advanced Path objects.""" |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
|
|
||
|
|
||
| def _parse_headers(headers: Headers, param_info: Dict[str, Any]) -> Any: | ||
| """Parse headers with advanced Header objects.""" |
There was a problem hiding this comment.
The docstring is redundant as it simply restates what the function name '_parse_headers' already clearly indicates. The comment does not provide any additional insight into complex logic or non-obvious implementation details.
🔍 This comment matches your effective_comments.mdc rule.
| """Parse headers with advanced Header objects.""" |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
|
|
||
|
|
||
| def _parse_body(body: Body, param_info: Dict[str, Any]) -> Any: | ||
| """Parse request body with Pydantic model validation.""" |
There was a problem hiding this comment.
The docstring is redundant as it just restates what can be understood from the function name '_parse_body' and the code implementation. The comment does not provide any additional context or explanation of non-obvious behavior.
🔍 This comment matches your effective_comments.mdc rule.
| """Parse request body with Pydantic model validation.""" |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
| return body | ||
|
|
||
|
|
||
| def _convert_type(value: Any, target_type: type) -> Any: |
There was a problem hiding this comment.
The docstring '"""Convert value to target type."""' is redundant as it simply restates what is already clear from the function name and type hints. The comment provides no additional insight or explanation beyond what the code itself conveys.
🔍 This comment matches your effective_comments.mdc rule.
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
| active: bool = Query(True, description="Whether user is active"), | ||
| tags: Optional[List[str]] = Query(None, description="Optional list of tags") | ||
| ): | ||
| """Example with typed query parameters.""" |
There was a problem hiding this comment.
This docstring is redundant as it merely restates what is already clear from the function name 'query_example' and its typed parameters. The comment adds no additional value or context beyond what the code itself expresses. According to the effective comments rule, comments should not state the obvious but rather explain 'why' when needed. This comment should be removed as the code is self-documenting.
🔍 This comment matches your effective_comments.mdc rule.
| """Example with typed query parameters.""" |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
|
|
||
| @app.get("/query/alias") | ||
| def query_alias_example(user_name: str = Query(..., alias="username")): | ||
| """Example with query parameter alias.""" |
There was a problem hiding this comment.
This docstring is redundant as the function name 'query_alias_example' and the clear parameter declaration with Query(alias='username') already indicate the purpose. The comment restates what is obvious from the code. According to the effective comments rule, we should avoid comments that don't add value beyond what the code expresses.
🔍 This comment matches your effective_comments.mdc rule.
| """Example with query parameter alias.""" |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
| user_id: int = Path(..., description="User ID"), | ||
| score: float = Path(..., description="User score") | ||
| ): | ||
| """Example with typed path parameters.""" |
There was a problem hiding this comment.
This docstring violates the effective comments rule by restating what is already evident from the function name 'path_example' and its typed Path parameters. The comment does not provide any additional context or explain non-obvious assumptions. Comments should clarify intent or complexity, not restate what the code already tells us.
🔍 This comment matches your effective_comments.mdc rule.
| """Example with typed path parameters.""" |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
| x_token: Optional[str] = Header(None, description="API token"), | ||
| user_agent: Optional[str] = Header(None, description="User agent") | ||
| ): | ||
| """Example with header parameters.""" |
There was a problem hiding this comment.
This docstring simply restates what is already clear from the function name 'header_example' and its Header parameter types. The comment violates the effective comments rule by not adding any value beyond what the code itself expresses. It should be removed as it doesn't explain any non-obvious aspects or design decisions.
🔍 This comment matches your effective_comments.mdc rule.
| """Example with header parameters.""" |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
| @@ -134,6 +135,17 @@ def wrapped_handler(*args, **kwargs): | |||
| if not request or (len(handler_params) == 1 and next(iter(handler_params)) is Request): | |||
| return handler(*args, **kwargs) | |||
|
|
|||
| # First try advanced parameter parsing | |||
There was a problem hiding this comment.
This comment is redundant as it simply restates what the code is doing in the subsequent lines. The code itself (calling parse_advanced_params) clearly indicates that advanced parameter parsing is being attempted first.
🔍 This comment matches your effective_comments.mdc rule.
| # First try advanced parameter parsing |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
| if len(advanced_params) == len(handler_params): | ||
| return handler(**advanced_params) | ||
| except Exception as e: | ||
| # If advanced parsing fails, fall back to original Robyn logic |
There was a problem hiding this comment.
This comment is redundant as the following line contains a log message that already explains the fallback behavior. The code structure with try/except also makes it clear that this is a fallback path.
🔍 This comment matches your effective_comments.mdc rule.
| # If advanced parsing fails, fall back to original Robyn logic |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
| # If advanced parsing fails, fall back to original Robyn logic | ||
| _logger.debug(f"Advanced parameter parsing failed, falling back to Robyn logic: {e}") | ||
|
|
||
| # Original Robyn parameter parsing logic as fallback |
There was a problem hiding this comment.
This comment is redundant as it restates what has already been communicated through both the code structure (try/except fallback pattern) and the explicit debug log message above.
🔍 This comment matches your effective_comments.mdc rule.
| # Original Robyn parameter parsing logic as fallback |
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
CodSpeed Performance ReportMerging #1247 will not alter performanceComparing Summary
Footnotes |
Description
This PR fixes #
Summary
This PR does....
PR Checklist
Please ensure that:
Pre-Commit Instructions:
High-level PR Summary
This PR adds Pydantic support to the Robyn web framework, introducing a more modern, type-safe parameter parsing system. The implementation includes new parameter types (
Query,Path,Header,Form) that enable automatic type conversion, validation, and better developer experience. The PR adds the necessary integration with Pydantic models for request body validation, comprehensive documentation inADVANCED_PARAMS.md, example applications, and integration tests. The router has been modified to try advanced parameter parsing first before falling back to the original Robyn parameter handling logic, ensuring backward compatibility.⏱️ Estimated Review Time: 1h 30m
💡 Review Order Suggestion
robyn/advanced_params.pyrobyn/router.pyrobyn/__init__.pyADVANCED_PARAMS.mdexamples/advanced_params_example.pyintegration_tests/test_advanced_params.pyquick_start_example.pypyproject.tomlReview by RecurseML
🔍 Review performed on ffb7ebc..7bbfa0a
✅ Files analyzed, no issues (1)
•
robyn/__init__.py⏭️ Files skipped (trigger manually) (2)
ADVANCED_PARAMS.mdpyproject.toml