openapi-generators / openapi-generators/openapi-python-client
Parameter-level descriptions are ignored in Python SDK generation; only schema descriptions are used
Ninguém assumiu esta issue ainda.
- Linguagem predominante
- Python
- Estrelas
- 2k
- Forks
- 293
- Merge médio
- 34min
- PRs com merge (30d)
- 1
Descrição
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!
Guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Direção de pesquisa
Nenhum arquivo-fonte ou teste é indicado na issue. Comece gerando um cliente Python a partir do repro de OpenAPI 3.1 fornecido e inspecione a documentação dos argumentos do método gerado. Está concluído quando parameter.description é usado para a documentação dos argumentos, enquanto as descrições do schema permanecem disponíveis para detalhes sobre o tipo ou o formato do valor.
Escrita pelo modelo de indexação a partir do texto da issue.
Avaliação
- Stack de tecnologia
- openapi, python
- Domínio
- api, tooling
- Tipo de issue
- Bug
- Dificuldade
- 3/5
- Tempo estimado
- 1-2 dias
- Status de atividade
- Estagnada
- Clareza
- Razoavelmente clara
- Facilidade para iniciantes
- 55/100