Python 是一种高级解释型编程语言，能够让你快速工作并更有效地集成系统。它以简洁的语法著称，强调可读性，从而降低了程序维护成本。Python 支持多种编程范式，包括过程式、面向对象和函数式编程。

Poetry 在软件开发语境下，是一个用于 Python 依赖管理和打包的工具。它允许你声明项目所依赖的库，并为你管理（安装/更新）这些库。

总之，将 Python 与 Poetry 结合使用，意味着开发基于 Python 的软件，且其依赖项由 Poetry 进行管理。

Python est un langage de programmation interprété de haut niveau qui vous permet de travailler rapidement et d'intégrer vos systèmes de manière plus efficace. Il est connu pour sa syntaxe facile qui met l'accent sur la lisibilité et réduit donc le coût de la maintenance du programme. Python prend en charge plusieurs paradigmes de programmation, y compris la programmation procédurale, orientée objet et fonctionnelle.

Poetry, dans un contexte logiciel, est un outil de gestion des dépendances et de paquetage en Python. Il vous permet de déclarer les bibliothèques dont dépend votre projet et il les gérera (installera/mettra à jour) pour vous.

Ensemble, utiliser Python avec Poetry signifie développer un logiciel basé sur Python dont les dépendances sont gérées par Poetry.

[tool.poetry]
name = "http-apis"
version = "0.1.0"
description = "Http Apis"
authors = ["user "]
license = "MIT"
readme = "README.md"
#packages = [{include = "devops_from_scratch_manual_process"}]

[tool.poetry.dependencies]
#python = "^3.10.6"
python = "^3.11"
sortedcontainers = "^2.4.0"
httpx = "^0.23.0"
pyzmq = "^25.1.0"
fastapi = "^0.97.0"
uvicorn = "^0.22.0"
requests = "^2.31.0"
openai = "^0.27.8"
whitenoise = "^6.2.0"
fontawesomefree = "^6.4.0"
typer = { version = "^0.9.0", extras = ["all"] }

#[tool.poetry.group.dev.dependencies]
#black = "^23.3.0"
#pytest = "7.3.1"

[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

此源代码展示了一个名为“http-apis”的项目。版本为 0.1.0，列出了作者的联系邮箱，并采用 MIT 许可证。该项目显然使用了许多依赖项，如 sortedcontainers、httpx、pyzmq、fastapi、uvicorn、requests、openai、whitenoise、fontawesomefree、typer 以及 Python 3.11 版本。该项目的构建系统需要“poetry-core”，并使用“poetry.core.masonry.api”后端进行构建。

潜在问题：

• packages 部分被注释掉了，这意味着该文件没有明确指出哪些包/模块应包含在分发版中。
• 'dev dependencies' 部分被注释掉了，因此此代码未指明任何开发阶段的依赖项，例如用于代码格式化的 black 或用于测试的 pytest。
• 如果系统 Python 不兼容，特定的 Python 版本可能会成为问题。

改进建议：

• 如果项目构建或开发需要 packages 和开发依赖项，则不应将其注释掉，这有助于贡献者快速设置环境。
• 将 Python 版本从 "^3.11" 改为 ">=3.11" 可能更好，这样项目也能在更新的 Python 版本上运行。
• 应更新 ReadMe 文件以包含这些详细信息，帮助用户进行初始设置并理解项目。

Ce code source indique un projet appelé "http-apis". Sa version est la 0.1.0, l'adresse e-mail de contact de l'auteur est mentionnée, et il est sous licence MIT. Le projet utilise manifestement une multitude de dépendances telles que sortedcontainers, httpx, pyzmq, fastapi, uvicorn, requests, openai, whitenoise, fontawesomefree, typer et la version 3.11 de Python. Le système de construction de ce projet requiert "poetry-core" et utilise le backend "poetry.core.masonry.api" pour la construction.

Problèmes potentiels :

• La section des paquets est commentée, ce qui signifie que ce fichier n'indique pas explicitement quels paquets/modules doivent être inclus dans la distribution.
• La section 'dépendances de développement' est commentée, donc ce code n'indique aucune dépendance de phase de développement telle que black pour le formatage du code ou pytest pour les tests.
• La version spécifique de Python pourrait poser problème si la version Python du système n'est pas compatible.

Améliorations :

• La section des paquets et des dépendances de développement ne devrait pas être commentée si elle est nécessaire pour la construction du projet ou pour le développement et peut aider les contributeurs à configurer rapidement leur environnement.
• Au lieu de conserver la version Python "^3.11", il serait préférable de spécifier ">=3.11" pour permettre au projet de fonctionner également avec les versions plus récentes de Python.
• Le fichier ReadMe devrait être mis à jour pour inclure ces détails et aider les utilisateurs avec la configuration initiale et la compréhension du projet.

Hurl 是一个用于 HTTP 请求的命令行工具和库。它允许你通过简单的命令发送 HTTP 请求，常被开发人员用于测试 API。

Hurl est un outil en ligne de commande et une bibliothèque pour les requêtes HTTP. Il vous permet d'envoyer des requêtes HTTP avec une commande simple et est souvent utilisé par les développeurs pour tester des API.

cargo install hurl

hurl --help

Run Hurl file(s) or standard input

Usage: hurl [OPTIONS] [input_files]...

Arguments:
  [input_files]...  Sets the input file to use

Options:
      --cacert 
          CA certificate to verify peer against (PEM format)
  -E, --cert 
          Client certificate file and password
      --key 
          Private key file name
      --color
          Colorize output
      --compressed
          Request compressed response (using deflate or gzip)
      --connect-timeout 
          Maximum time allowed for connection [default: 300]
      --connect-to 
          For a request to the given HOST1:PORT1 pair, connect to HOST2:PORT2 instead
  -b, --cookie 
          Read cookies from FILE
  -c, --cookie-jar 
          Write cookies to FILE after running the session (only for one session)
      --error-format 
          Control the format of error messages [default: short] [possible values: short, long]
      --fail-at-end
          Fail at end
      --file-root 
          Set root filesystem to import files [default: current directory]
  -L, --location
          Follow redirects
      --glob 
          Specify input files that match the given GLOB. Multiple glob flags may be used
      --ignore-asserts
          Ignore asserts defined in the Hurl file
  -i, --include
          Include the HTTP headers in the output
  -k, --insecure
          Allow insecure SSL connections
      --interactive
          Turn on interactive mode
      --json
          Output each Hurl file result to JSON
      --max-redirs 
          Maximum number of redirects allowed, -1 for unlimited redirects [default: 50]
  -m, --max-time 
          Maximum time allowed for the transfer [default: 300]
      --no-color
          Do not colorize output
      --no-output
          Suppress output. By default, Hurl outputs the body of the last response
      --noproxy 
          List of hosts which do not use proxy
  -o, --output 
          Write to FILE instead of stdout
      --path_as_is
          Tell Hurl to not handle sequences of /../ or /./ in the given URL path
  -x, --proxy <[PROTOCOL://]HOST[:PORT]>
          Use proxy on given protocol/host/port
      --report-html 
          Generate HTML report to DIR
      --report-junit 
          Write a Junit XML report to FILE
      --resolve 
          Provide a custom address for a specific host and port pair
      --retry 
          Maximum number of retries, 0 for no retries, -1 for unlimited retries [default: 0]
      --retry-interval 
          Interval in milliseconds before a retry [default: 1000]
      --ssl-no-revoke
          (Windows) This option tells Hurl to disable certificate revocation checks. WARNING: this
          option loosens the SSL security, and by using this flag you ask for exactly that.
      --test
          Activate test mode
      --to-entry 
          Execute Hurl file to ENTRY_NUMBER (starting at 1)
  -A, --user-agent 
          Specify the User-Agent string to send to the HTTP server
  -u, --user 
          Add basic Authentication header to each request
      --variable 
          Define a variable
      --variables-file 
          Define a properties file in which you define your variables
      --verbose
          Turn verbose
      --very-verbose
          Turn on verbose output, including HTTP response and libcurl logs
  -h, --help
          Print help
  -V, --version
          Print version

OpenAPI 规范 (OAS)，前身为 Swagger，是一种用于描述、生产、消费和可视化 RESTful Web 服务的机器可读接口文件规范。它有助于为 REST API 定义一种标准的、与语言无关的接口，使人类和计算机无需直接访问源代码、文档或网络流量即可理解服务功能。

让我们从 JSON Schema 开始。JSON Schema 是一种验证 JSON 数据结构的强大工具。它以清晰、简洁且易于阅读（对人类和机器而言）的方式描述了你现有的数据格式。它也是与语言无关的，这意味着你可以在任何支持 JSON 的编程语言中使用它。

那么，OpenAPI 规范在其中扮演什么角色呢？JSON Schema 构成了 OpenAPI 规范的一部分，后者是前者的扩展，旨在描述和验证 REST API。

通过使用 OAS 创建 API，开发人员可以在无需访问 API 源代码或阅读大量文档的情况下，理解、使用并可视化 API。设计良好的 OAS 有助于简化 API 开发。

TM Forum 的 OpenAPIs (TMF 规范的一部分) 是 OpenAPI 规范实际应用的一个例子。它们是一套提供从管理客户和产品到处理订单和计费等各种功能的 API，并根据全球公认的标准开发。

就其在现代软件开发中的实用性而言，它们非常有用：

1. 文档：自动生成包含交互功能的文档的能力，减少了工作量，对消费者和测试都有利。
2. 代码生成：OAS 支持以不同语言生成客户端、服务器和测试用例，这极大地加快了开发过程。
3. API 设计与规划：它们允许采用“设计优先”的方法，即你可以先规划 API，然后再执行。

总的来说，OpenAPI 规范及其基础设施中的 JSON Schema，通过使 API 开发更快、更简单、更可靠，正在推动软件构建方式的范式转变。

Spécification OpenAPI (OAS), autrefois connue sous le nom de Swagger, est une spécification pour les fichiers d'interface lisibles par machine pour décrire, produire, consommer et visualiser des services web RESTful. Elle aide à définir une interface standard, indépendante du langage, pour les API REST, ce qui permet aux humains et aux ordinateurs de comprendre les capacités du service sans un accès direct au code source, à la documentation, ou au trafic réseau.

Commençons avec les schémas JSON. Un schéma JSON est un outil puissant pour valider la structure des données JSON. Il décrit votre format de données existant de manière claire, concise et facile à lire (pour les humains et les machines). Il est également indépendant du langage, ce qui signifie que vous pouvez l'utiliser avec n'importe quel langage de programmation qui supporte JSON.

Alors, comment les spécifications OpenAPI s'intègrent-elles dans le tableau ? Les schémas JSON forment une partie des spécifications OpenAPI, qui en sont une extension, et servent à décrire et à valider les API REST.

En créant des API avec OAS, les développeurs peuvent comprendre et utiliser l'API, et former une visualisation de l'API, sans avoir accès au code source de l'API ou la nécessité de lire une documentation extensive. Une OAS bien conçue aide à simplifier le développement des API.

Les OpenAPI du TM Forum (partie des spécifications TMF) sont un exemple d'utilisation réelle des spécifications OpenAPI. Il s'agit d'un ensemble d'API qui fournissent une variété de fonctions, de la gestion des clients et des produits à la manipulation des commandes et de la facturation, et qui sont développées selon des normes mondialement reconnues.

En termes d'utilité dans le développement de logiciels modernes, ils sont extrêmement utiles pour :

1. Documentation: La capacité à générer automatiquement de la documentation, avec interactivité incluse, réduit le travail et est bénéfique pour les consommateurs et les tests.
2. Génération de code: L'OAS soutient la génération de clients, de serveurs et de cas test dans différentes langues, ce qui accélère considérablement le processus de développement.
3. Conception et planification d'API: Ils permettent une approche de conception en premier, où vous pouvez planifier votre API pour ensuite l'exécuter.

En somme, les spécifications OpenAPI, avec les schémas JSON dans leur infrastructure, facilitent un changement de paradigme dans la façon dont nous construisons des logiciels en rendant le développement d'API plus rapide, plus facile et plus fiable.

FastAPI 是一个现代、快速（高性能）的 Web 框架，用于使用 Python 3.6+ 构建 API，基于标准的 Python 类型提示和异步编程能力。其主要特点是快速、简单、符合 Python 习惯、注重性能且健壮，并具有自动交互式 API 文档等功能。

FastAPI 基于 Starlette（用于 Web 部分）和 Pydantic（用于数据部分）。它被设计为非常快速且易于使用，对类型检查、IDE 集成和其他现代编程特性提供了出色的支持。由于它构建在标准 Python 类型提示之上，它能生成完全交互式的 API，这些提示也有助于数据验证、序列化和文档编制。

FastAPI 利用 Pydantic 模型和 Python 类型提示来生成 OpenAPI 规范。OpenAPI 规范是 REST API 的标准化格式，提供了一种描述 API 结构的方法，有助于生成正确的请求和响应。

这是一个基础 FastAPI 项目的有趣代码示例，包括一个提供 POST、GET、PATCH、PUT 和 DELETE 端点的 API，以及基于 Python Requests 库的客户端代码：

FastAPI est un framework web moderne, rapide (à haute performance), destiné à la création d'APIs avec Python 3.6+ basé sur les indications de type Python standard et les capacités de programmation asynchrone. Les caractéristiques clés sont la rapidité, la facilité, le côté Pythonic, l'accent sur les performances, et la robustesse, avec des fonctionnalités comme la documentation automatique interactive de l'API.

FastAPI est construit sur Starlette pour les parties web et Pydantic pour les parties de données. Il est conçu pour être très rapide et facile à utiliser, avec un excellent support pour le contrôle de type, l'intégration IDE, et d'autres avantages de la programmation moderne. Il produit une API entièrement interactive grâce à son utilisation des indications de type Python standard, qui aident également à la validation des données, à la sérialisation et à la documentation.

FastAPI utilise les modèles Pydantic et les indications de type Python pour générer spécifications OpenAPI. Les spécifications OpenAPI sont le format standardisé pour les API REST qui offrent un moyen de décrire la structure de l'API, ce qui aide à générer des requêtes et des réponses correctes.

Voici un exemple de code intéressant d'un projet FastAPI de base, comprenant une API qui sert des points de terminaison POST, GET, PATCH, PUT, et DELETE ainsi qu'un code client basé sur la bibliothèque Python Requests:

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel):
    name: str
    price: float

items = []

@app.post("/items/")
def create_item(item: Item):
    items.append(item.dict())
    return items[-1]

@app.get("/items/")
def read_items():
    return items

@app.patch("/items/{item_id}")
def update_item(item_id: int, item: Item):
    items[item_id] = item.dict()
    return items[item_id]

@app.put("/items/{item_id}")
def replace_item(item_id: int, item: Item):
    items[item_id] = item.dict()
    return items[item_id]

@app.delete("/items/{item_id}")
def delete_item(item_id: int):
    items.pop(item_id)
    return {'Message': 'Item deleted'}

以下是如何使用 Python Requests 库来调用此 API：

uvicorn server:app --reload

此命令假设 FastAPI 脚本位于名为 server.py 的文件中，并且包含一个名为 app 的 FastAPI 实例。

import requests

# POST a new item
requests.post('http://localhost:8000/items/', json={'name': 'item1', 'price': 20.0})

# GET all items
response = requests.get('http://localhost:8000/items/')
print(response.json())

# PATCH an existing item
requests.patch('http://localhost:8000/items/0', json={'name': 'item2', 'price': 30.0})

# PUT (replace) an existing item
requests.put('http://localhost:8000/items/0', json={'name': 'item3', 'price': 40.0})

# DELETE an item
requests.delete('http://localhost:8000/items/0')

使用 Hurl：

# For POST:

POST http://localhost:8000/items/
Content-Type: application/json

{
  "name": "item1",
  "price": 20.0
}

# For GET:

GET http://localhost:8000/items/

#For PATCH:

PATCH http://localhost:8000/items/0
Content-Type: application/json

{
  "name": "item2",
  "price": 30.0
}

# For PUT:

PUT http://localhost:8000/items/0
Content-Type: application/json

{
  "name": "item3",
  "price": 40.0
}

# For DELETE:

DELETE http://localhost:8000/items/0

hurl client.hurl

访问 Swagger 文档：http://localhost:8000/docs

HTTP 谓词 是指示对给定资源执行所需操作的方法。它们是 HTTP 请求不可或缺的一部分，以下是最常见的几种：

1. GET：GET 方法类似于去图书馆向图书管理员索要特定书籍。你请求读取或下载数据，但不会更改任何内容。
2. POST：POST 方法可以比作写一封信然后寄出。你正在向服务器发送数据以创建新资源。当你上传照片或发送消息时会使用它。
3. PUT：PUT 方法就像修改报告或文章的草稿。你正在完整地更新现有资源。因此，如果你想更新网站上的个人资料信息，你很可能会使用 PUT 方法。
4. DELETE：DELETE 方法顾名思义——就像把一张纸扔进垃圾桶。你正在要求服务器删除资源。
5. PATCH：PATCH 就像修正错别字或在已写的文章中添加新句子。本质上，你是在部分修改资源。

请记住，虽然这些类比解释了基本概念，但 HTTP 谓词的实际工作方式要复杂一些。这些差异源于服务器设置、授权需求以及你所交互的 Web 应用程序的具体配置等因素。

Les verbes HTTP sont des méthodes qui indiquent l'action souhaitée à effectuer sur une ressource donnée. Ils sont essentiels aux requêtes HTTP, et voici les plus courants:

1. GET: La méthode GET est analogue à aller à une bibliothèque et demander à la bibliothécaire un livre spécifique. Vous demandez à lire ou télécharger des données, mais vous ne changez rien.
2. POST: La méthode POST peut être comparée à l'écriture d'une lettre puis à son envoi. Vous envoyez des données au serveur pour créer une nouvelle ressource. Elle est utilisée lorsque vous téléchargez une photo ou envoyez un message.
3. PUT: La méthode PUT est comme réviser un brouillon d'un rapport ou d'un article. Vous mettez à jour une ressource existante dans son intégralité. Donc, si vous vouliez mettre à jour vos informations de profil sur un site, vous utiliseriez probablement la méthode PUT pour le faire.
4. DELETE: La méthode DELETE est assez explicite - c'est comme jeter un morceau de papier à la poubelle. Vous demandez au serveur de supprimer une ressource.
5. PATCH: La méthode PATCH est comme corriger une faute de frappe ou ajouter une nouvelle phrase à un essai que vous avez écrit. Essentiellement, vous modifiez partiellement une ressource.

Rappelez-vous que bien que ces analogies expliquent les concepts de base, le fonctionnement réel des verbes HTTP est un peu plus compliqué. Ces différences proviennent de choses comme les paramètres du serveur, les besoins d'autorisation, et la configuration particulière de l'application web avec laquelle vous interagissez.

HTTP 标头 是可在 HTTP 请求中使用的请求和响应标头，用于提供有关请求或响应的信息。HTTP 标头可以包含主机、用户代理、授权、内容类型、内容长度等字段。它们很有用，因为它们提供了一种结构化的方式来传递有关请求或响应的元数据。

JSON Web Token (JWT) 是一种紧凑且 URL 安全的方式，用于表示要在双方之间传输的声明。它们用于 JSON 格式的身份验证和安全信息传输。在 API 的情况下，JWT 被用作身份识别和访问控制的一种方法。它们可以包含用户的身份，提供某种形式的用户访问控制，甚至可能携带 API 操作权限。

JWT 与 HTTP 标头相关，因为 JWT 通常在 HTTP Authorization 标头中传递。它通常以 'Authorization: Bearer {token}' 的形式传输。服务器随后可以使用 JWT 中包含的信息来验证用户并授权对资源的访问。

总而言之，JWT 令牌提供了一种在双方之间安全传输信息的方法，作为在 API 中验证用户和授权操作的一种方式。结合 HTTP 标头，它们确保了一种安全传输和访问数据的方式。

Les en-têtes HTTP sont les en-têtes de requête et de réponse qui peuvent être utilisés dans une requête HTTP pour fournir des informations sur la requête ou la réponse. Les en-têtes HTTP peuvent inclure des champs pour l'hôte, l'agent utilisateur, l'autorisation, le type de contenu, la longueur du contenu, et bien d'autres. Ils sont utiles car ils fournissent un moyen structuré de transmettre des métadonnées sur une requête ou une réponse.

Le jeton Web JSON (JWT) est un moyen compact et sûr pour l'URL de représenter les revendications à transférer entre deux parties. Ils sont utilisés dans l'authentification et la transmission sécurisée des informations au format JSON. Dans le cas des API, les JWT sont utilisés comme moyen d'identification et de contrôle d'accès. Ils peuvent contenir l'identité d'un utilisateur, fournir une forme de contrôle d'accès utilisateur, et peut-être même porter des permissions d'opération d'API.

JWT & les en-têtes HTTP sont liés parce que le JWT est souvent passé dans l'en-tête d'autorisation HTTP. Il est généralement transmis sous la forme 'Authorization: Bearer {token}'. Le serveur peut alors utiliser les informations contenues dans le JWT pour authentifier l'utilisateur et autoriser l'accès aux ressources.

Pour résumer, les jetons JWT fournissent une méthode pour transmettre de manière sécurisée des informations entre les parties, agissant comme un moyen d'authentifier les utilisateurs et d'autoriser les actions dans les API. En combinaison avec les en-têtes HTTP, ils assurent un moyen sûr de transmettre et d'accéder aux données.

代码优先 (Code First) 和 契约优先 (Contract First) 是使用 OpenAPI 规范设计 API 时使用的两种不同策略。

• 代码优先 方法意味着开发人员先编写代码，然后从代码生成 OpenAPI 规范。此过程包括在代码中创建端点、请求/响应类型等，然后将其转换为 OpenAPI 契约。这种方法的优点是开发人员可以在无需等待契约的情况下开始构建 API。然而，这可能导致 API 表面不那么一致且难以预测，因为契约是从代码派生出来的，并可能受到代码技术细节的影响。
• 另一方面，/契约优先/ 方法从设计 API 契约开始。OpenAPI 规范（契约）是预先设置好的，然后开发代码以满足此契约。这种方法在编码开始前促进了对 API 外观的清晰理解，促进了更好的跨团队沟通，并使 API 消费者能够从一开始就提供对需求和要求的反馈。这可能会带来设计更好、更可预测的 API。缺点是 API 的任何更改都需要更改契约，并向消费者传达这些更改。

graph TD;
  A[Start] --> B[Decision Point];
  B --> |Contract First| C[Write API Contract];
  C --> D[Develop Application Code Based on Contract];
  D --> E[End];
  B --> |Code First| F[Write Application Code];
  F --> G[Generate API Contract From Code];
  G --> E;

Code First et Contract First sont deux stratégies différentes utilisées pour concevoir des API en utilisant la spécification OpenAPI.

• La méthodologie Code First signifie que les développeurs commencent par écrire le code et génèrent ensuite la spécification OpenAPI à partir du code. Ce processus comprend la création de points finaux, de types de demande/réponse, etc. dans le code, qui est ensuite transformé en contrat OpenAPI. L'avantage de cette approche est que les développeurs peuvent commencer à construire l'API sans avoir à attendre un contrat. Cependant, cela peut conduire à une surface d'API moins cohérente et plus difficile à prévoir car le contrat est dérivé du code, et peut être influencé par les aspects techniques de ce code.
• D'autre part, la méthodologie Contract First commence par la conception du contrat API. La spécification OpenAPI (le contrat) est établie d'abord, puis le code est développé pour satisfaire ce contrat. Cette méthode favorise une compréhension claire de ce à quoi l'API ressemblera avant que le codage ait commencé, favorisant une meilleure communication entre les équipes et permettant aux consommateurs de l'API de fournir leurs commentaires sur les besoins et les exigences dés le début. Cela pourrait entraîner une API mieux conçue et plus prévisible. L'inconvénient est que tout changement à l'API nécessitera des modifications du contrat et une communication aux consommateurs à propos de ces changements.

graph TD;
  A[Début] --> B[Point de Décision];
  B --> |Contract First| C[Écrire le Contrat API];
  C --> D[Développer le Code de l'Application basé sur le Contrat];
  D --> E[Fin];
  B --> |Code First| F[Écrire le Code de l'Application];
  F --> G[Générer le Contrat API à partir du Code];
  G --> E;

# std
import json
import os

# 3rd party
import openai


def run_completion(prompt, engine="davinci", max_tokens=5):
    openai.api_key = os.environ.get("OPENAI_KEY")
    response = openai.Completion.create(
        engine=engine,
        prompt=prompt,
        max_tokens=max_tokens,
    )
    print(response)
    return response


def run_chat_completion(messages, model="gpt4"):
    openai.api_key = os.environ.get("OPENAI_KEY")
    response = openai.ChatCompletion.create(
        model=model,
        messages=messages,
    )
    print(response)
    return response


if __name__ == "__main__":
    run_completion("Tout juste un test", engine="davinci")
    run_completion("Tout juste un petit coucou", engine="davinci", max_tokens=256)
    run_chat_completion([
        dict(role="user", content="Quel temps fait t'il a Abidjan?")
    ], model="gpt-4-0613")

# std
import json
import os

# 3rd party
import openai


def run_chat_completion(messages, model="gpt4", functions=None, function_call="auto"):
    openai.api_key = os.environ.get("OPENAI_KEY")
    response = openai.ChatCompletion.create(
        model=model,
        messages=messages,
        functions=functions,
        function_call=function_call
    )
    print(response)
    return response


if __name__ == "__main__":
    run_chat_completion(
        [
            dict(role="user", content="Quel temps fait t'il a Abidjan?")
        ],
        model="gpt-4-0613",
        functions=[
            dict(
                name="la_meteo",
                description="Retourne la météo d'une ville",
                parameters=dict(
                    type="object",
                    properties=dict(
                        location=dict(
                            type="string",
                            description="Le nom de la ville, ou le code postal de la ville, ex: Abidjan, ou 00225"
                        ),
                        unit=dict(
                            type="string",
                            enum=["celsius", "fahrenheit"],
                        )
                    ),
                    required=["location"]
                )
            )
        ],
        function_call="auto"
    )