openapi-generators / openapi-generators/openapi-python-client
Parameter-level descriptions are ignored in Python SDK generation; only schema descriptions are used
Chưa có ai nhận issue này.
- Ngôn ngữ chính
- Python
- Star
- 2k
- Fork
- 293
- Merge trung bình
- 34 phút
- Pull request đã merge (30 ngày)
- 1
Mô tả
Describe the bug
When generating a Python client, parameter documentation is taken from the parameter schema’s description, while the parameter object’s top-level description is ignored or not preferred.
OpenAPI defines description on the Parameter Object (“A brief description of the parameter…”) and separately allows description on schemas via the Schema Object / JSON Schema annotation model. These fields describe different layers of the API, but the current Python generation appears to only use the schema-level description for parameter docs. 
OpenAPI Spec File
openapi: 3.1.0
info:
title: Description precedence repro
version: 1.0.0
paths:
/tasks/export:
get:
operationId: export_tasks
summary: Export tasks
parameters:
- in: query
name: since
required: false
description: Only include tasks changed after this timestamp.
schema:
type: integer
format: int64
description: Unix timestamp in milliseconds.
responses:
"200":
description: OK
Desktop (please complete the following information):
- OS: macOS Tahoe 26.3
- Python Version: 3.10
- openapi-python-client version: 0.28.2
Additional context
Expected behavior:
For simple parameters, generated method argument docs should prefer parameter.description, optionally appending schema.description as secondary value-format detail.
Example desired output:
def export_tasks(self, since: int | None = None) -> Response:
"""
Args:
since: Only include tasks changed after this timestamp.
Unix timestamp in milliseconds.
"""
For reusable rich schemas, the split should be:
- method argument docs from parameter.description
- model/type docs from schema.description
- field docs from property description
This would preserve the distinction OpenAPI makes between operation-level parameter semantics and reusable type semantics. This seems to be true for response bodies too.
Happy to work on this myself!
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Hướng nghiên cứu
Issue không nêu tệp nguồn hay bài kiểm thử nào. Hãy bắt đầu bằng cách tạo một client Python từ repro OpenAPI 3.1 được cung cấp và kiểm tra tài liệu về các đối số của phương thức được tạo. Được xem là hoàn tất khi parameter.description được dùng cho tài liệu về đối số, trong khi các mô tả schema vẫn có sẵn cho các chi tiết về kiểu hoặc định dạng giá trị.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- openapi, python
- Lĩnh vực
- api, tooling
- Loại issue
- Lỗi
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức độ hoạt động
- Đình trệ
- Độ rõ ràng
- Khá rõ ràng
- Mức phù hợp với người mới
- 55/100