Orivel Orivel
Ouvrir le menu

Implémenter un limiteur de débit Token Bucket thread-safe en Python

Comparez les reponses des modeles pour cette tache benchmark en Programmation et consultez scores, commentaires et exemples lies.

Connectez-vous ou inscrivez-vous pour utiliser les likes et favoris. Inscription

X f L

Sommaire

Vue d ensemble de la tache

Genres de comparaison

Programmation

Modele createur de la tache

Modeles participants

Modeles evaluateurs

Consigne de la tache

Écrivez une classe Python nommée `TokenBucketRateLimiter` qui implémente l'algorithme du token bucket pour la limitation de débit. L'implémentation doit être thread-safe et ne doit pas utiliser de bibliothèques externes pour la gestion d'état (comme Redis). La classe doit respecter les spécifications suivantes : 1. Une méthode `__init__(self, capacity, refill_rate)` : * `capacity` : Le nombre maximal de jetons que le seau peut contenir. * `refill_rate` : Le nombre de jetons qui sont ajoutés au seau p...

Afficher plus

Écrivez une classe Python nommée `TokenBucketRateLimiter` qui implémente l'algorithme du token bucket pour la limitation de débit. L'implémentation doit être thread-safe et ne doit pas utiliser de bibliothèques externes pour la gestion d'état (comme Redis). La classe doit respecter les spécifications suivantes : 1. Une méthode `__init__(self, capacity, refill_rate)` : * `capacity` : Le nombre maximal de jetons que le seau peut contenir. * `refill_rate` : Le nombre de jetons qui sont ajoutés au seau par seconde. 2. Une méthode `consume(self, tokens)` : * Cette méthode tente de consommer un nombre donné de `tokens` depuis le seau. * Elle doit retourner `True` si les jetons peuvent être consommés avec succès, et `False` sinon. * Le seau doit être re-rempli avec des jetons en fonction du temps écoulé depuis le dernier appel avant d'essayer de consommer. 3. Sécurité des threads : * La classe doit être sûre à utiliser depuis plusieurs threads concurrents. Toutes les opérations qui modifient l'état du seau (comme le remplissage et la consommation de jetons) doivent être atomiques. Fournissez l'implémentation complète de la classe avec les imports nécessaires.

Informations complementaires

L'algorithme du token bucket est une méthode courante pour limiter le débit des requêtes vers un service. Imaginez un seau de capacité fixe qui est continuellement rempli de jetons à un rythme constant. Chaque requête entrante doit prélever un certain nombre de jetons du seau pour être traitée. Si le seau contient suffisamment de jetons, la requête est autorisée et les jetons sont retirés. Sinon, la requête est rejetée. Cette approche permet des rafales de requêtes jusqu'à la capacité du seau, tout en imposant un d...

Afficher plus

L'algorithme du token bucket est une méthode courante pour limiter le débit des requêtes vers un service. Imaginez un seau de capacité fixe qui est continuellement rempli de jetons à un rythme constant. Chaque requête entrante doit prélever un certain nombre de jetons du seau pour être traitée. Si le seau contient suffisamment de jetons, la requête est autorisée et les jetons sont retirés. Sinon, la requête est rejetée. Cette approche permet des rafales de requêtes jusqu'à la capacité du seau, tout en imposant un débit moyen au fil du temps. Cette tâche est pertinente pour construire des services web robustes, des passerelles d'API (API gateways), ou tout système qui doit contrôler le taux d'opérations entrantes pour éviter la surcharge.

Politique d evaluation

Une réponse de haute qualité doit fournir une implémentation Python correcte et complète de la classe. L'évaluation se concentrera sur les critères suivants : 1. **Correctness of Algorithm:** L'implémentation doit refléter fidèlement l'algorithme du token bucket. Elle doit calculer correctement le remplissage des jetons en fonction du temps écoulé et gérer correctement la limite de capacité du seau. 2. **Thread Safety:** La solution doit être réellement thread-safe. L'utilisation de primitives de synchronisation...

Afficher plus

Une réponse de haute qualité doit fournir une implémentation Python correcte et complète de la classe. L'évaluation se concentrera sur les critères suivants : 1. **Correctness of Algorithm:** L'implémentation doit refléter fidèlement l'algorithme du token bucket. Elle doit calculer correctement le remplissage des jetons en fonction du temps écoulé et gérer correctement la limite de capacité du seau. 2. **Thread Safety:** La solution doit être réellement thread-safe. L'utilisation de primitives de synchronisation appropriées (comme `threading.Lock`) pour protéger l'état partagé est cruciale. Les solutions présentant des conditions de concurrence sont incorrectes. 3. **Code Quality:** Le code doit être propre, lisible et suivre les conventions Python standard (`PEP 8`). Des commentaires doivent être utilisés lorsque nécessaire pour expliquer une logique complexe. 4. **Robustness and Edge Cases:** L'implémentation doit gérer gracieusement les cas limites, tels qu'une demande de consommation de plus de jetons que la capacité totale du seau, la consommation de zéro jeton, et l'état initial du seau.

Reponses

import threading import time class TokenBucketRateLimiter: def __init__(self, capacity, refill_rate): """ Initialiser le limiteur de débit de bucket de jetons. :param capacity: Nombre maximum de jetons que le bucket peut contenir. :param refill_rate: Nombre de jetons ajoutés au bucket par seconde. """ self.capacity = capacity self.refill_rate = refill_rate self._tokens = capacity # Commence avec un bucket plein self._last_refill_time = time.monotonic() self._lock = threading.Lock() def _refill(self): """ R...

Afficher la reponse complete

import threading import time class TokenBucketRateLimiter: def __init__(self, capacity, refill_rate): """ Initialiser le limiteur de débit de bucket de jetons. :param capacity: Nombre maximum de jetons que le bucket peut contenir. :param refill_rate: Nombre de jetons ajoutés au bucket par seconde. """ self.capacity = capacity self.refill_rate = refill_rate self._tokens = capacity # Commence avec un bucket plein self._last_refill_time = time.monotonic() self._lock = threading.Lock() def _refill(self): """ Remplir le bucket en fonction du temps écoulé depuis le dernier remplissage. Cette méthode doit être appelée pendant que le verrou est détenu. """ now = time.monotonic() elapsed = now - self._last_refill_time tokens_to_add = elapsed * self.refill_rate self._tokens = min(self.capacity, self._tokens + tokens_to_add) self._last_refill_time = now def consume(self, tokens): """ Tenter de consommer un nombre donné de jetons du bucket. :param tokens: Nombre de jetons à consommer. :return: True si les jetons ont été consommés avec succès, False sinon. """ if tokens <= 0: raise ValueError("Le nombre de jetons à consommer doit être positif.") if tokens > self.capacity: # Ne peut jamais être satisfait même avec un bucket plein return False with self._lock: self._refill() if self._tokens >= tokens: self._tokens -= tokens return True return False

Resultat

#1 | Gagnant

Votes gagnants

3 / 3

Score moyen

81
Modeles evaluateurs Google Gemini 2.5 Flash

Score total

89

Commentaire global

La réponse A fournit une implémentation hautement correcte et bien structurée du limiteur de débit de jetons (Token Bucket Rate Limiter). La qualité de son code est excellente, avec des docstrings claires et le respect des conventions Python. Elle implémente correctement la sécurité des threads et gère explicitement les cas limites spécifiés, ce qui en fait une solution robuste et maintenable.

Afficher le detail de l evaluation

Exactitude

Poids 35%
90

L'algorithme de remplissage et de consommation des jetons est correctement implémenté. La limite de capacité est correctement appliquée et la logique de remplissage basée sur le temps est saine.

Completude

Poids 20%
90

La réponse fournit une implémentation de classe complète avec toutes les méthodes spécifiées (`__init__`, `consume`) et les importations nécessaires.

Qualite du code

Poids 20%
88

Le code est propre, lisible et suit les conventions Python standard. Il comprend d'excellentes docstrings pour les méthodes publiques et un commentaire clair pour la méthode privée `refill`, améliorant considérablement la maintenabilité.

Valeur pratique

Poids 15%
88

L'implémentation utilise correctement `threading.Lock` pour assurer la sécurité des threads, la rendant adaptée aux environnements concurrents. C'est une solution pratiquement valable.

Respect des consignes

Poids 10%
90

La solution gère explicitement tous les cas limites mentionnés dans la section 'Robustesse et Cas Limites' de l'invite : lever une `ValueError` pour des `tokens` non positifs et retourner immédiatement `False` si `tokens` dépasse la `capacity`. L'état initial est également correctement défini.

Modeles evaluateurs OpenAI GPT-5.2

Score total

79

Commentaire global

Implémente un limiteur de bucket de jetons correct avec temps monotone, recharges fractionnaires, plafonnement de capacité et verrouillage approprié autour de la recharge+consommation. Il gère également le cas limite important des requêtes plus grandes que la capacité en retournant False. Petit inconvénient : il lève une exception si tokens<=0 (dépendant de la politique ; certains pourraient préférer traiter 0 comme un True sans opération) et il ne valide pas les entrées de capacité/taux de recharge.

Afficher le detail de l evaluation

Exactitude

Poids 35%
82

Recharge correcte du bucket de jetons basée sur le temps monotone écoulé, plafonne à la capacité et effectue la recharge+consommation de manière atomique sous un verrou. Utilise correctement les jetons fractionnaires.

Completude

Poids 20%
80

Fournit une classe complète avec les importations, une aide interne pour la recharge et une méthode de consommation ; inclut la gestion explicite des jetons>capacité. Manque de validation pour les valeurs de capacité/taux de recharge.

Qualite du code

Poids 20%
76

Lisible, style PEP8, avec des docstrings expliquant le comportement et les attentes en matière de verrouillage. Structure simple.

Valeur pratique

Poids 15%
72

Pratique pour une utilisation typique ; le retour immédiat de False pour les requêtes impossibles et volumineuses est utile. Lever une exception si tokens<=0 peut être gênant dans certaines intégrations ; pas de validation des paramètres pour la capacité/le taux de recharge.

Respect des consignes

Poids 10%
83

Répond aux exigences : thread-safe, pas de bibliothèques d'état externes, méthodes et comportement corrects, et inclut les importations nécessaires.

Modeles evaluateurs Anthropic Claude Opus 4.6

Score total

73

Commentaire global

La réponse A fournit une implémentation correcte, complète et bien documentée du limiteur de débit de bucket de jetons. Elle implémente correctement l'algorithme avec une sécurité de thread appropriée à l'aide de threading.Lock, gère les cas limites tels que la consommation de plus de jetons que la capacité (renvoie False) et la consommation de zéro ou de jetons négatifs (lève une ValueError). Le code comprend des docstrings claires expliquant le but et les paramètres de chaque méthode. Il utilise time.monotonic() pour un suivi fiable du temps. Le code est propre, lisible et suit bien les conventions Python.

Afficher le detail de l evaluation

Exactitude

Poids 35%
75

Implémente correctement l'algorithme du bucket de jetons avec un calcul de remplissage approprié, une limitation de capacité et des opérations de consommation atomiques. Gère le cas limite de demande de plus de jetons que la capacité en renvoyant False tôt. Lève une ValueError pour les demandes de jetons non positives.

Completude

Poids 20%
70

Couvre les __init__, consume et la sécurité de thread requis. Gère les cas limites : jetons zéro/négatifs (ValueError), jetons dépassant la capacité (renvoie False). Commence avec un bucket plein. Inclut toutes les importations nécessaires.

Qualite du code

Poids 20%
75

Bien documenté avec des docstrings claires pour la classe et chaque méthode. Les descriptions des paramètres sont fournies. Le code est propre, lisible et suit les conventions PEP 8. La méthode privée _refill est clairement indiquée comme nécessitant que le verrou soit détenu.

Valeur pratique

Poids 15%
70

Prêt à être utilisé dans des scénarios de production. Le retour anticipé pour les jetons dépassant la capacité est une optimisation pratique. La ValueError pour une entrée invalide aide au débogage. Utilise time.monotonic() pour une synchronisation fiable.

Respect des consignes

Poids 10%
75

Suit toutes les instructions : implémente la classe avec le nom spécifié, __init__ avec la capacité et le taux de remplissage, la méthode consume renvoyant True/False, la sécurité de thread avec threading.Lock, et inclut les importations nécessaires. Fournit une implémentation de classe complète comme demandé.

Reponse B: OpenAI GPT-5.4

import threading import time class TokenBucketRateLimiter: def __init__(self, capacity, refill_rate): if capacity <= 0: raise ValueError("capacity must be greater than 0") if refill_rate <= 0: raise ValueError("refill_rate must be greater than 0") self.capacity = float(capacity) self.refill_rate = float(refill_rate) self._tokens = float(capacity) self._last_refill_time = time.monotonic() self._lock = threading.Lock() def _refill(self): now = time.monotonic() elapsed = now - self._last_refill_time if...

Afficher la reponse complete

import threading import time class TokenBucketRateLimiter: def __init__(self, capacity, refill_rate): if capacity <= 0: raise ValueError("capacity must be greater than 0") if refill_rate <= 0: raise ValueError("refill_rate must be greater than 0") self.capacity = float(capacity) self.refill_rate = float(refill_rate) self._tokens = float(capacity) self._last_refill_time = time.monotonic() self._lock = threading.Lock() def _refill(self): now = time.monotonic() elapsed = now - self._last_refill_time if elapsed > 0: added_tokens = elapsed * self.refill_rate self._tokens = min(self.capacity, self._tokens + added_tokens) self._last_refill_time = now def consume(self, tokens): if tokens <= 0: raise ValueError("tokens must be greater than 0") tokens = float(tokens) with self._lock: self._refill() if self._tokens >= tokens: self._tokens -= tokens return True return False

Resultat

#2

Votes gagnants

0 / 3

Score moyen

76
Modeles evaluateurs Google Gemini 2.5 Flash

Score total

86

Commentaire global

La réponse B offre une implémentation fonctionnellement correcte avec des améliorations de robustesse précieuses, telles que la validation initiale des paramètres et l'utilisation de flottants pour la précision. Cependant, son inconvénient majeur est l'absence de docstrings pour ses méthodes, ce qui nuit considérablement à sa qualité de code, sa lisibilité et sa maintenabilité.

Afficher le detail de l evaluation

Exactitude

Poids 35%
92

L'algorithme principal est correctement implémenté. L'utilisation de flottants pour les décomptes de jetons et les taux offre une meilleure précision, ce qui constitue une légère amélioration de la correction dans un contexte de limitation de débit.

Completude

Poids 20%
90

La réponse fournit une implémentation de classe complète avec toutes les méthodes spécifiées (`__init__`, `consume`) et les importations nécessaires.

Qualite du code

Poids 20%
65

Le code manque de docstrings pour ses méthodes, ce qui réduit considérablement sa lisibilité et sa maintenabilité. Bien que les noms des variables soient clairs, l'absence de documentation est un inconvénient majeur.

Valeur pratique

Poids 15%
92

L'implémentation est thread-safe grâce à `threading.Lock`. De plus, la validation initiale des `capacity` et `refill_rate` comme étant positifs, ainsi que l'utilisation de flottants pour la précision, améliorent considérablement sa robustesse pratique.

Respect des consignes

Poids 10%
85

La réponse gère le cas `tokens <= 0` en levant une `ValueError` et définit correctement l'état initial. Elle gère implicitement la consommation de plus de jetons que la capacité, mais manque d'une sortie anticipée explicite comme la réponse A. La validation `__init__` est un bon ajout mais n'est pas explicitement mentionnée dans les exemples de cas limites du prompt.

Modeles evaluateurs OpenAI GPT-5.2

Score total

76

Commentaire global

Implémente la logique principale du seau à jetons avec une horloge monotone et un verrouillage approprié autour du remplissage+consommation, et ajoute une validation utile pour la capacité et le taux de remplissage. Cependant, il manque le cas limite clé où une requête dépasse la capacité totale ; une telle requête devrait immédiatement renvoyer False, mais cette implémentation renverra toujours False sans le documenter/gérer explicitement (et continuera de remplir/verrouiller à chaque fois). Il lève également une exception pour tokens<=0 (encore une fois, dépendant de la politique).

Afficher le detail de l evaluation

Exactitude

Poids 35%
76

Le remplissage principal et la consommation atomique sous verrouillage sont corrects et utilisent une horloge monotone avec plafonnement de la capacité. Manque la gestion explicite pour les tokens > capacité, ce qui est un cas limite attendu dans l'énoncé ; le comportement est implicitement toujours-faux mais non géré/court-circuité.

Completude

Poids 20%
71

Classe complète avec imports et méthodes d'aide, et inclut la validation pour la capacité/le taux de remplissage. Manque la gestion du cas limite mentionné dans l'énoncé pour la consommation supérieure à la capacité totale.

Qualite du code

Poids 20%
79

Propre et concis, avec une validation claire et une utilisation cohérente des flottants. Moins de commentaires/docstrings que A mais toujours lisible et bien structuré.

Valeur pratique

Poids 15%
74

Les validations pratiques pour la capacité/le taux de remplissage améliorent la sécurité. Le manque de gestion explicite des requêtes surdimensionnées et la levée d'exception pour tokens<=0 réduisent légèrement l'ergonomie.

Respect des consignes

Poids 10%
82

Répond aux exigences principales et inclut les imports nécessaires et la sécurité des threads. Ne répond pas au cas limite explicitement mentionné (consommer plus que la capacité totale) dans la description de la tâche.

Modeles evaluateurs Anthropic Claude Opus 4.6

Score total

67

Commentaire global

La réponse B fournit une implémentation correcte avec une sécurité des threads appropriée. Elle ajoute une validation des entrées pour les paramètres du constructeur (la capacité et le taux de remplissage doivent être positifs), ce qui est une bonne touche de robustesse. Elle convertit explicitement les valeurs en flottants, ce qui ajoute une certaine sécurité de type. Cependant, elle manque de docstrings et de commentaires, ce qui réduit la lisibilité. Elle ne gère pas non plus le cas limite où les jetons demandés dépassent la capacité (elle retournera toujours False en pratique, mais ne court-circuite pas avant d'acquérir le verrou). La vérification elapsed > 0 dans _refill est une optimisation mineure mais pas strictement nécessaire.

Afficher le detail de l evaluation

Exactitude

Poids 35%
70

Implémente correctement l'algorithme du seau à jetons avec une logique de remplissage et de consommation appropriée. La sécurité des threads est correctement implémentée. Cependant, il ne gère pas le cas où les jetons demandés dépassent la capacité comme un retour anticipé, ce qui signifie qu'il acquerra toujours le verrou et tentera le remplissage avant de retourner inévitablement False. La garde elapsed > 0 est une optimisation mineure mais inutile.

Completude

Poids 20%
70

Couvre les méthodes requises __init__, consume et la sécurité des threads. Ajoute une validation du constructeur pour que la capacité et le taux de remplissage soient positifs, ce qui est un bon ajout en termes de complétude. Gère la consommation de jetons nulle/négative. Inclut toutes les importations nécessaires. Cependant, il manque la vérification explicite du dépassement de capacité dans consume.

Qualite du code

Poids 20%
55

Manque de docstrings ou de commentaires. Bien que le code lui-même soit propre et lisible, l'absence de documentation réduit considérablement la qualité du code. Les conversions explicites en flottants ajoutent une certaine sécurité de type, mais sans explication de la raison pour laquelle elles sont effectuées.

Valeur pratique

Poids 15%
70

Prêt à être utilisé dans des scénarios de production. La validation du constructeur empêche une mauvaise configuration avec des valeurs de capacité ou de taux de remplissage invalides, ce qui est d'une grande valeur pratique. La conversion explicite en flottants garantit une arithmétique cohérente. Utilise time.monotonic() pour une synchronisation fiable.

Respect des consignes

Poids 10%
65

Suit les instructions principales : implémente la classe avec le nom correct, les méthodes __init__ et consume, la sécurité des threads avec Lock, et inclut les importations. Cependant, la tâche mentionne la gestion de la consommation de zéro jeton comme cas limite, et la réponse B lève une erreur pour cela plutôt que de la gérer gracieusement. Manque également la documentation qu'implique une 'implémentation complète'.

Resume comparatif

Pour chaque tache et discussion, le classement final est determine par agregation des rangs par evaluateur (rang moyen + departage Borda). Le score moyen est affiche a titre indicatif.

Evaluateurs: 3

Votes gagnants

3 / 3

Score moyen

81
Voir cette reponse

Votes gagnants

0 / 3

Score moyen

76
Voir cette reponse

Resultats de l evaluation

Modeles evaluateurs Anthropic Claude Opus 4.6

Raison du gagnant

La réponse A l'emporte principalement en raison d'une meilleure qualité de code (docstrings, commentaires, documentation claire) et d'une gestion légèrement meilleure des cas limites (retour explicite de False lorsque les jetons dépassent la capacité sans avoir besoin d'acquérir le verrou). Les deux réponses sont correctes dans leur algorithme de base et leur sécurité de thread. La documentation supérieure de la réponse A et le cas limite de vérification de capacité lui donnent un avantage, en particulier sur le critère de qualité du code qui a un poids important. La validation du constructeur de la réponse B est une bonne idée, mais ne compense pas le manque de documentation.

Modeles evaluateurs OpenAI GPT-5.2

Raison du gagnant

La réponse A l'emporte car elle correspond plus entièrement aux attentes du jeton-balle et à la gestion des cas limites en rejetant explicitement les consommations supérieures à la capacité du seau, tout en maintenant un comportement de remplissage et de consommation correct et thread-safe. La réponse B est proche mais moins complète/robuste en ce qui concerne les cas limites spécifiés, ce qui pèse lourdement sur la correction et la complétude.

Modeles evaluateurs Google Gemini 2.5 Flash

Raison du gagnant

La réponse A l'emporte principalement en raison de sa qualité de code supérieure, qui comprend des docstrings complètes et un code clair et lisible. Bien que la réponse B offre des fonctionnalités de robustesse précieuses telles que la validation initiale des paramètres et la précision des décimales, son manque de documentation nuit considérablement à sa qualité globale et à sa maintenabilité, surtout compte tenu du poids du critère « qualité du code ». La réponse A gère également explicitement tous les cas limites spécifiés, ce qui contribue à son score élevé en matière de suivi des instructions.

X f L