Orivel Orivel
Abrir menu

Implementar un limitador de tasa Token Bucket seguro para subprocesos en Python

Compara respuestas de modelos para esta tarea benchmark de Programación y revisa puntuaciones, comentarios y ejemplos relacionados.

Inicia sesion o registrate para usar me gusta y favoritos. Registrarse

X f L

Indice

Resumen de la tarea

Generos de Comparacion

Programación

Modelo creador de la tarea

Modelos participantes

Modelos evaluadores

Enunciado de la tarea

Escribe una clase en Python llamada `TokenBucketRateLimiter` que implemente el algoritmo Token Bucket para limitar la tasa. La implementación debe ser segura para subprocesos (thread-safe) y no debe usar ninguna biblioteca externa para la gestión del estado (como Redis). La clase debe tener las siguientes especificaciones: 1. Un `__init__(self, capacity, refill_rate)` método: * `capacity`: El número máximo de tokens que el cubo puede contener. * `refill_rate`: El número de tokens que se añaden al cub...

Mostrar mas

Escribe una clase en Python llamada `TokenBucketRateLimiter` que implemente el algoritmo Token Bucket para limitar la tasa. La implementación debe ser segura para subprocesos (thread-safe) y no debe usar ninguna biblioteca externa para la gestión del estado (como Redis). La clase debe tener las siguientes especificaciones: 1. Un `__init__(self, capacity, refill_rate)` método: * `capacity`: El número máximo de tokens que el cubo puede contener. * `refill_rate`: El número de tokens que se añaden al cubo por segundo. 2. Un `consume(self, tokens)` método: * Este método intenta consumir un número dado de `tokens` del cubo. * Debe devolver `True` si los tokens pueden consumirse con éxito, y `False` en caso contrario. * Antes de intentar consumir, el cubo debe rellenarse con tokens en función del tiempo transcurrido desde la última llamada. 3. Seguridad para subprocesos: * La clase debe ser segura para usarse desde múltiples hilos concurrentes. Todas las operaciones que modifican el estado del cubo (como rellenar y consumir tokens) deben ser atómicas. Proporcione la implementación completa de la clase con las importaciones necesarias.

Informacion complementaria

El algoritmo Token Bucket es un método común para limitar la tasa de solicitudes a un servicio. Imagínese un cubo con una capacidad fija que se rellena constantemente con tokens a una velocidad constante. Cada solicitud entrante debe tomar un cierto número de tokens del cubo para ser procesada. Si el cubo tiene suficientes tokens, la solicitud se permite y los tokens se eliminan. Si no, la solicitud se rechaza. Este enfoque permite ráfagas de solicitudes hasta la capacidad del cubo, mientras impone una tasa promedi...

Mostrar mas

El algoritmo Token Bucket es un método común para limitar la tasa de solicitudes a un servicio. Imagínese un cubo con una capacidad fija que se rellena constantemente con tokens a una velocidad constante. Cada solicitud entrante debe tomar un cierto número de tokens del cubo para ser procesada. Si el cubo tiene suficientes tokens, la solicitud se permite y los tokens se eliminan. Si no, la solicitud se rechaza. Este enfoque permite ráfagas de solicitudes hasta la capacidad del cubo, mientras impone una tasa promedio a lo largo del tiempo. Esta tarea es relevante para construir servicios web robustos, gateways de API o cualquier sistema que necesite controlar la tasa de operaciones entrantes para evitar sobrecarga.

Politica de evaluacion

Una respuesta de alta calidad debe proporcionar una implementación correcta y completa de la clase en Python. La evaluación se centrará en los siguientes criterios: 1. **Corrección del algoritmo:** La implementación debe reflejar con precisión el algoritmo Token Bucket. Debe calcular correctamente el relleno de tokens en función del tiempo transcurrido y manejar apropiadamente el límite de capacidad del cubo. 2. **Seguridad para subprocesos:** La solución debe ser genuinamente segura para subprocesos. El uso de...

Mostrar mas

Una respuesta de alta calidad debe proporcionar una implementación correcta y completa de la clase en Python. La evaluación se centrará en los siguientes criterios: 1. **Corrección del algoritmo:** La implementación debe reflejar con precisión el algoritmo Token Bucket. Debe calcular correctamente el relleno de tokens en función del tiempo transcurrido y manejar apropiadamente el límite de capacidad del cubo. 2. **Seguridad para subprocesos:** La solución debe ser genuinamente segura para subprocesos. El uso de primitivas de sincronización apropiadas (como `threading.Lock`) para proteger el estado compartido es crítico. Las soluciones con condiciones de carrera son incorrectas. 3. **Calidad del código:** El código debe ser limpio, legible y seguir las convenciones estándar de Python (PEP 8). Se deben usar comentarios cuando sean necesarios para explicar lógica compleja. 4. **Robustez y casos límite:** La implementación debe manejar de forma elegante los casos límite, como una solicitud para consumir más tokens que la capacidad total del cubo, consumir cero tokens y el estado inicial del cubo.

Respuestas

Respuesta: import threading import time class TokenBucketRateLimiter: def __init__(self, capacity, refill_rate): """ Inicializa el limitador de tasa Token Bucket. :param capacity: Número máximo de tokens que puede contener el bucket. :param refill_rate: Número de tokens añadidos al bucket por segundo. """ self.capacity = capacity self.refill_rate = refill_rate self._tokens = capacity # Comienza con el bucket lleno self._last_refill_time = time.monotonic() self._lock = threading.Lock() def _refill(self): """...

Mostrar respuesta completa

Respuesta: import threading import time class TokenBucketRateLimiter: def __init__(self, capacity, refill_rate): """ Inicializa el limitador de tasa Token Bucket. :param capacity: Número máximo de tokens que puede contener el bucket. :param refill_rate: Número de tokens añadidos al bucket por segundo. """ self.capacity = capacity self.refill_rate = refill_rate self._tokens = capacity # Comienza con el bucket lleno self._last_refill_time = time.monotonic() self._lock = threading.Lock() def _refill(self): """ Rellena el bucket según el tiempo transcurrido desde el último relleno. Este método debe llamarse mientras se mantiene el bloqueo. """ 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): """ Intenta consumir una cantidad determinada de tokens del bucket. :param tokens: Número de tokens a consumir. :return: True si los tokens se consumieron correctamente, False en caso contrario. """ if tokens <= 0: raise ValueError("El número de tokens a consumir debe ser positivo.") if tokens > self.capacity: # Nunca podrá satisfacerse ni siquiera con un bucket lleno return False with self._lock: self._refill() if self._tokens >= tokens: self._tokens -= tokens return True return False

Resultado

#1 | Ganador

Votos ganadores

3 / 3

Puntuacion media

81
Modelos evaluadores Google Gemini 2.5 Flash

Puntuacion total

89

Comentario general

La respuesta A proporciona una implementación altamente correcta y bien estructurada del limitador de velocidad Token Bucket. Su calidad de código es excelente, con docstrings claras y adhesión a las convenciones de Python. Implementa correctamente la seguridad de hilos y maneja explícitamente los casos extremos especificados, lo que la convierte en una solución robusta y mantenible.

Ver detalle de evaluacion

Correccion

Peso 35%
90

El algoritmo para recargar y consumir tokens está implementado correctamente. El límite de capacidad se aplica adecuadamente y la lógica de recarga basada en el tiempo es sólida.

Integridad

Peso 20%
90

La respuesta proporciona una implementación de clase completa con todos los métodos especificados (`__init__`, `consume`) y las importaciones necesarias.

Calidad del codigo

Peso 20%
88

El código es limpio, legible y sigue las convenciones estándar de Python. Incluye excelentes docstrings para los métodos públicos y un comentario claro para el método privado de recarga, lo que mejora significativamente la mantenibilidad.

Valor practico

Peso 15%
88

La implementación utiliza correctamente `threading.Lock` para garantizar la seguridad de hilos, lo que la hace adecuada para entornos concurrentes. Es una solución prácticamente sólida.

Seguimiento de instrucciones

Peso 10%
90

La solución maneja explícitamente todos los casos extremos mencionados en la sección 'Robustez y casos extremos' del prompt: genera `ValueError` para `tokens` no positivos y devuelve `False` inmediatamente si `tokens` excede la `capacity`. El estado inicial también se establece correctamente.

Modelos evaluadores OpenAI GPT-5.2

Puntuacion total

79

Comentario general

Implementa un limitador de cubo de fichas correcto con tiempo monótono, recargas fraccionarias, limitación de capacidad y bloqueo adecuado alrededor de la recarga+consumo. También maneja el importante caso límite de solicitudes mayores que la capacidad devolviendo Falso. Desventaja menor: lanza una excepción en tokens<=0 (dependiente de la política; algunos podrían preferir tratar 0 como un True sin efecto) y no valida las entradas de capacidad/tasa de recarga.

Ver detalle de evaluacion

Correccion

Peso 35%
82

Recarga correcta del cubo de fichas basada en el tiempo monótono transcurrido, limita a la capacidad y realiza la recarga+consumo atómicamente bajo un bloqueo. Utiliza fichas fraccionarias apropiadamente.

Integridad

Peso 20%
80

Proporciona una clase completa con importaciones, un ayudante de recarga interno y un método de consumo; incluye el manejo explícito de tokens>capacidad. Falta validación para los valores de capacidad/tasa de recarga.

Calidad del codigo

Peso 20%
76

Legible, estilo PEP8, con docstrings que explican el comportamiento y las expectativas de bloqueo. Estructura sencilla.

Valor practico

Peso 15%
72

Práctico para uso típico; el Falso inmediato para solicitudes grandes imposibles es útil. Lanzar una excepción en tokens<=0 puede ser inconveniente en algunas integraciones; no hay validación de parámetros para capacidad/tasa de recarga.

Seguimiento de instrucciones

Peso 10%
83

Cumple los requisitos: seguro para hilos, sin bibliotecas de estado externas, métodos y comportamiento correctos, e incluye las importaciones necesarias.

Modelos evaluadores Anthropic Claude Opus 4.6

Puntuacion total

73

Comentario general

La respuesta A proporciona una implementación correcta, completa y bien documentada del limitador de tasa de cubo de tokens. Implementa correctamente el algoritmo con la seguridad de hilos adecuada utilizando threading.Lock, maneja casos extremos como consumir más tokens que la capacidad (devuelve False) y consumir cero o tokens negativos (genera ValueError). El código incluye docstrings claros que explican el propósito y los parámetros de cada método. Utiliza time.monotonic() para un seguimiento fiable del tiempo. El código es limpio, legible y sigue bien las convenciones de Python.

Ver detalle de evaluacion

Correccion

Peso 35%
75

Implementa correctamente el algoritmo del cubo de tokens con el cálculo de recarga adecuado, el límite de capacidad y las operaciones de consumo atómicas. Maneja el caso extremo de solicitar más tokens que la capacidad devolviendo False de forma temprana. Genera ValueError para solicitudes de tokens no positivas.

Integridad

Peso 20%
70

Cubre los __init__, consume y seguridad de hilos requeridos. Maneja casos extremos: tokens cero/negativos (ValueError), tokens que exceden la capacidad (devuelve False). Comienza con un cubo lleno. Incluye todas las importaciones necesarias.

Calidad del codigo

Peso 20%
75

Bien documentado con docstrings claros para la clase y cada método. Se proporcionan descripciones de los parámetros. El código es limpio, legible y sigue las convenciones de PEP 8. Se señala claramente que el método privado _refill requiere que el bloqueo esté activo.

Valor practico

Peso 15%
70

Listo para usar en escenarios de producción. El retorno temprano para tokens que exceden la capacidad es una optimización práctica. El ValueError para entradas inválidas ayuda en la depuración. Utiliza time.monotonic() para una temporización fiable.

Seguimiento de instrucciones

Peso 10%
75

Sigue todas las instrucciones: implementa la clase con el nombre especificado, __init__ con capacidad y tasa de recarga, método consume que devuelve True/False, seguridad de hilos con threading.Lock, e incluye las importaciones necesarias. Proporciona una implementación completa de la clase según lo solicitado.

Respuesta 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...

Mostrar respuesta completa

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

Resultado

#2

Votos ganadores

0 / 3

Puntuacion media

76
Modelos evaluadores Google Gemini 2.5 Flash

Puntuacion total

86

Comentario general

La respuesta B ofrece una implementación funcionalmente correcta con algunas mejoras valiosas de robustez, como la validación inicial de parámetros y el uso de flotantes para la precisión. Sin embargo, su inconveniente importante es la falta de docstrings para sus métodos, lo que afecta gravemente su calidad de código, legibilidad y mantenibilidad.

Ver detalle de evaluacion

Correccion

Peso 35%
92

El algoritmo central está implementado correctamente. El uso de flotantes para los recuentos de tokens y las tasas proporciona una mejor precisión, lo que supone una ligera mejora en la corrección en un contexto de limitación de tasas.

Integridad

Peso 20%
90

La respuesta proporciona una implementación de clase completa con todos los métodos especificados (`__init__`, `consume`) y las importaciones necesarias.

Calidad del codigo

Peso 20%
65

El código carece de docstrings para sus métodos, lo que reduce significativamente su legibilidad y mantenibilidad. Si bien los nombres de las variables son claros, la ausencia de documentación es un gran inconveniente.

Valor practico

Peso 15%
92

La implementación es segura para hilos utilizando `threading.Lock`. Además, la validación inicial de que `capacity` y `refill_rate` sean positivos, junto con el uso de flotantes para la precisión, mejora significativamente su robustez práctica.

Seguimiento de instrucciones

Peso 10%
85

La solución maneja `tokens <= 0` lanzando `ValueError` y establece correctamente el estado inicial. Maneja implícitamente el consumo de más tokens que la capacidad, pero carece de una salida temprana explícita como la Respuesta A. La validación de `__init__` es una buena adición pero no está explícitamente listada en los ejemplos de casos extremos del prompt.

Modelos evaluadores OpenAI GPT-5.2

Puntuacion total

76

Comentario general

Implementa la lógica principal del bucket de tokens con tiempo monótono y bloqueo adecuado para recarga+consumo, y añade validaciones útiles para capacidad y tasa de recarga. Sin embargo, omite el caso límite clave donde una solicitud excede la capacidad total; dicha solicitud debería devolver False inmediatamente, pero esta implementación devolverá siempre False sin documentarlo/manejarlo explícitamente (y seguirá recargando/bloqueando cada vez). También lanza un error si los tokens son <=0 (de nuevo, depende de la política).

Ver detalle de evaluacion

Correccion

Peso 35%
76

La recarga principal y el consumo atómico bajo bloqueo son correctos y utilizan tiempo monótono con limitación de capacidad. Carece de manejo explícito para tokens > capacidad, que es un caso límite esperado en el prompt; el comportamiento es implícitamente siempre falso pero no se maneja/acorta.

Integridad

Peso 20%
71

Clase completa con importaciones y métodos auxiliares, e incluye validación para capacidad/tasa de recarga. Omite el manejo del caso límite mencionado en el prompt para consumir más que la capacidad total.

Calidad del codigo

Peso 20%
79

Limpio y conciso, con validación clara y uso consistente de flotantes. Menos comentarios/docstrings que A pero aún legible y bien estructurado.

Valor practico

Peso 15%
74

Las validaciones prácticas para capacidad/tasa de recarga mejoran la seguridad. La falta de manejo explícito de solicitudes sobredimensionadas y el lanzamiento de errores para tokens <=0 reducen ligeramente la ergonomía.

Seguimiento de instrucciones

Peso 10%
82

Cumple con los requisitos principales e incluye las importaciones necesarias y seguridad de hilos. No cumple con el caso límite explícitamente señalado (consumir más que la capacidad total) en la descripción de la tarea.

Modelos evaluadores Anthropic Claude Opus 4.6

Puntuacion total

67

Comentario general

La respuesta B proporciona una implementación correcta con la debida seguridad de hilos. Añade validación de entrada para los parámetros del constructor (capacidad y tasa de recarga deben ser positivos), lo cual es un buen toque de robustez. Convierte explícitamente los valores a flotante, lo que añade cierta seguridad de tipos. Sin embargo, carece de docstrings y comentarios, lo que reduce la legibilidad. Tampoco maneja el caso límite en el que los tokens solicitados exceden la capacidad (siempre devolverá Falso en la práctica, pero no se detiene antes de adquirir el bloqueo). La comprobación elapsed > 0 en _refill es una optimización menor pero no estrictamente necesaria.

Ver detalle de evaluacion

Correccion

Peso 35%
70

Implementa correctamente el algoritmo del cubo de tokens con una lógica de recarga y consumo adecuada. La seguridad de hilos está implementada correctamente. Sin embargo, no maneja el caso en que los tokens exceden la capacidad como un retorno temprano, lo que significa que aún adquirirá el bloqueo e intentará la recarga antes de devolver inevitablemente Falso. La protección elapsed > 0 es una optimización menor pero innecesaria.

Integridad

Peso 20%
70

Cubre los métodos requeridos __init__, consume y la seguridad de hilos. Añade validación del constructor para que la capacidad y la tasa de recarga sean positivas, lo cual es una buena adición de completitud. Maneja el consumo de cero/tokens negativos. Incluye todas las importaciones necesarias. Sin embargo, carece de la comprobación explícita de que la capacidad se excede en consume.

Calidad del codigo

Peso 20%
55

Carece de docstrings o comentarios. Si bien el código en sí es limpio y legible, la ausencia de documentación reduce significativamente la calidad del código. Las conversiones explícitas a flotante añaden cierta seguridad de tipos, pero sin explicar por qué se realizan.

Valor practico

Peso 15%
70

Lista para usar en escenarios de producción. La validación del constructor evita la mala configuración con valores de capacidad o tasa de recarga no válidos, lo cual es prácticamente valioso. La conversión explícita a flotante garantiza una aritmética consistente. Utiliza time.monotonic() para una temporización fiable.

Seguimiento de instrucciones

Peso 10%
65

Sigue las instrucciones principales: implementa la clase con el nombre correcto, los métodos __init__ y consume, seguridad de hilos con Lock, e incluye las importaciones. Sin embargo, la tarea menciona el manejo del consumo de cero tokens como un caso límite, y la Respuesta B genera un error para ello en lugar de manejarlo con gracia. También carece de la documentación que implica una 'implementación completa'.

Resumen comparativo

Para cada tarea y discusion, el orden final se decide por agregacion de rangos por evaluador (rango promedio + desempate Borda). La puntuacion media se muestra como referencia.

Evaluadores: 3

Votos ganadores

3 / 3

Puntuacion media

81
Ver esta respuesta

Votos ganadores

0 / 3

Puntuacion media

76
Ver esta respuesta

Resultados de evaluacion

Modelos evaluadores Anthropic Claude Opus 4.6

Motivo del ganador

La respuesta A gana principalmente por una mejor calidad de código (docstrings, comentarios, documentación clara) y un manejo ligeramente mejor de los casos límite (devuelve explícitamente False cuando los tokens exceden la capacidad sin necesidad de adquirir el bloqueo). Ambas respuestas son correctas en su algoritmo principal y seguridad de hilos. La documentación superior de la respuesta A y el caso límite de verificación de capacidad le dan una ventaja, particularmente en el criterio de calidad del código que tiene un peso significativo. La validación del constructor de la respuesta B es un buen detalle, pero no compensa la falta de documentación.

Modelos evaluadores OpenAI GPT-5.2

Motivo del ganador

La Respuesta A gana porque coincide más plenamente con las expectativas del token-bucket y el manejo de casos extremos al rechazar explícitamente los consumos mayores que la capacidad del bucket, al tiempo que mantiene un comportamiento de recarga y consumo correcto y seguro para hilos. La Respuesta B está cerca pero es menos completa/robusta con respecto a los casos extremos especificados, lo que tiene un gran peso en la corrección y la completitud.

Modelos evaluadores Google Gemini 2.5 Flash

Motivo del ganador

La Respuesta A gana principalmente debido a su calidad de código superior, que incluye docstrings completos y código claro y legible. Si bien la Respuesta B ofrece algunas características de robustez valiosas como la validación inicial de parámetros y la precisión de punto flotante, su falta de documentación resta significativamente a su calidad general y mantenibilidad, especialmente dado el peso del criterio de 'calidad del código'. La Respuesta A también maneja explícitamente todos los casos extremos especificados, lo que contribuye a su sólida puntuación de seguimiento de instrucciones.

X f L