Python is a high-level, interpreted programming language that lets you work quickly and integrates your systems more effectively. It's known for its easy syntax that emphasizes readability and therefore reduces the cost of program maintenance. Python supports multiple programming paradigms, including procedural, object-oriented, and functional programming.

Poetry, in a software context, is a tool for dependency management and packaging in Python. It allows you to declare the libraries your project depends on and it will manage (install/update) them for you.

Together, using Python with Poetry means developing a python-based software which dependencies are managed by 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"

This source code indicates a project called "http-apis." It's version 0.1.0, the author's contact email address is mentioned, and it's under MIT license. The project evidently utilizes a bunch of dependencies such as sortedcontainers, httpx, pyzmq, fastapi, uvicorn, requests, openai, whitenoise, fontawesomefree, typer and python version 3.11. The build system of this project requires "poetry-core" and uses the "poetry.core.masonry.api" backend for building.

Potential issues:

• The packages section is commented which means that this file does not indicate explicitly which packages/modules should be included in the distribution.
• The 'dev dependencies' section commented out, so this code does not indicate any development phase dependencies such as black for code formatting or pytest for testing.
• The specific Python version could be an issue if the system Python is not compatible.

Improvements:

• The packages and dev dependencies section should not be commented out if they are required for the project build or for the development and can help contributors set up their environment quickly.
• Instead of keeping the Python version "^3.11", it can be better to specify ">=3.11" to allow the project to run on the newer Python versions as well.
• The ReadMe file should be updated to include these details and help the users with the initial setup and understanding of the project.

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 is a command-line tool and library for HTTP requests. It allows you to send HTTP requests with a straightforward command and it is often used by developers for testing APIs.

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 Specification (OAS), formerly known as Swagger, is a specification for machine-readable interface files for describing, producing, consuming, and visualizing RESTful web services. It helps define a standard, language-agnostic interface for REST APIs, which allows both humans and computers to comprehend service capabilities without a direct access to the source code, documentation, or network traffic.

Let's begin with JSON Schemas. A JSON Schema is a powerful tool for validating the structure of JSON data. It describes your existing data format clear, concise and easy to read (for both humans and machines). It's also language agnostic, meaning you can use it with any programming language that has JSON support.

Now, how do OpenAPI Specifications fit into the picture? JSON Schemas form a part of OpenAPI Specifications, which is an extension of it, and cater to describe and validate REST APIs.

By creating APIs with OAS, developers can understand and use the API, and form a visualization of the API, without having access to the source code of the API or the need to read through extensive documentation. A well-designed OAS helps simplify API development.

TM Forum's OpenAPIs (part of TMF specifications) are an example of real-world use of OpenAPI Specifications. They are a suite of APIs that provide a variety of functions from managing customers and products to handling orders and billing, and are developed under globally recognized standards.

In terms of their usefulness in modern software development, they are extremely useful for:

1. Documentation: The ability to auto-generate documentation, with included interactivity, reduces work and is beneficial for consumers and testing.
2. Code Generation: OAS supports generation of clients, servers, and test cases in different languages, which greatly speeds up the development process.
3. API design and planning: They allow for a design-first approach, where you can plan your API and then execute it.

Overall, OpenAPI Specifications, with JSON Schemas in their infrastructure, are facilitating a paradigm shift in the way we build software by making API development faster, easier, and more reliable.

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 is a modern, fast (high-performance), web framework for building APIs with Python 3.6+ based on standard Python type hints and asynchronous programming capabilities. The key features are fast, easy, Pythonic, performance focused, and robust, with features like automatic interactive API documentation.

FastAPI is built on Starlette for the web parts and Pydantic for the data parts. It is designed to be very fast and easy to use, with excellent support for type checking, IDE integration, and other modern programming goodies. It produces a fully interactive API thanks to it being built to use standard Python type hints, which also aid in data validation, serialization, and documentation.

FastAPI utilizes Pydantic models and Python type hints to generate OpenAPI specifications. OpenAPI specs are the standardized format for REST APIs that provide a way to describe the structure of the API, which helps in generating correct requests and responses.

Here is an interesting code example of a basic FastAPI project, including an API that serves POST, GET, PATCH, PUT, and DELETE endpoints along with a client code based on the Python Requests library:

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 des 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'}

And here's how you may consume this API using the Python Requests library:

uvicorn server:app --reload

This command assumes that the FastAPI script is in a file named server.py and that it includes an instance of FastAPI named app.

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')

Using 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

Visit the Swagger Docs at http://localhost:8000/docs

HTTP verbs are methods that indicate the desired action to be performed on a given resource. They are integral to HTTP requests, and here are the most common ones:

1. GET: The GET method is analogous to going to a library and asking the librarian for a specific book. You're requesting to read or download data, but not changing anything.
2. POST: The POST method can be likened to writing a letter and then mailing it out. You're sending data to the server to create a new resource. It's used when you upload a photo or send a message.
3. PUT: The PUT method is like revising a draft of a report or article. You're updating an existing resource in its entirety. So, if you wanted to update your profile information on a site, you'd likely use the PUT method to do so.
4. DELETE: The DELETE method is pretty self-explanatory – it's like throwing a piece of paper into the trash. You're asking the server to remove a resource.
5. PATCH: PATCH is like fixing a typo or adding a new sentence to an essay you've written. Essentially, you're partially modifying a resource.

Remember that while these analogies explain the basic concepts, the actual workings of HTTP verbs are a bit more complicated. These differences come from things like server settings, authorization needs, and the particular configuration of the web application you're interacting with.

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.

Translate the following text to french:

HTTP Headers are the request and response headers that can be used in an HTTP request to provide information about the request or response. HTTP headers can include fields for the host, user agent, authorization, content type, content length, and many others. They are useful because they provide a structured way to pass metadata about a request or response.

JSON Web Token (JWT) is a compact, URL-safe way of representing claims to be transferred between two parties. They are used in authentication and secure transmission of information in JSON format. In the case of APIs, JWTs are used as a method of identification and access control. They can contain a user's identity, provide some form of user access control, and potentially even carry API operation permissions.

JWT & HTTP headers are related because the JWT is often passed in the HTTP Authorization header. It is generally transmitted in the form 'Authorization: Bearer {token}'. The server can then use the information contained in the JWT to authenticate the user and authorize access to resources.

To sum it up, JWT Tokens provide a method to securely transmit information between parties, acting as a way to authenticate users and authorize actions in APIs. In combination with HTTP headers, they ensure a safe way of transmitting and accessing data.

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 and Contract First are two different strategies used for designing APIs using the OpenAPI Specification.

• Code First methodology means that developers start by writing the code and then generate the OpenAPI specification from the code. This process includes the creation of endpoints, request/response types, etc. in the code, which is then transformed into an OpenAPI contract. The advantage of this approach is that developers can begin building out the API without having to wait for a contract. However, this can lead to a less consistent and harder to predict API surface as the contract is derived from the code, and can be influenced by the technicalities of that code.
• On the other hand, Contract First methodology starts with designing the API contract. The OpenAPI specification (the contract) is set up front, and then the code is developed to satisfy this contract. This method promotes a clear understanding of what the API will look like before any coding has begun, fostering better cross-team communication and enabling API consumers to provide their input on needs and requirements from the beginning. This could result in a better-designed and more predictable API. The downside is that any changes to the API will require contract changes and communication to the consumers about those changes.

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"
    )