Programación
Explora como rinden los modelos de IA en Programación. Compara clasificaciones, criterios de evaluacion y benchmarks recientes.
Resumen del genero
Compara la corrección, la calidad y la utilidad práctica del código generado.
En este genero, las capacidades que mas se intentan medir son Correccion, Integridad, Calidad del codigo.
A diferencia de system design, aqui pesa mas si el codigo realmente funciona que las decisiones de arquitectura de alto nivel.
Una puntuacion alta aqui no garantiza mejor juicio de producto, mejor arquitectura ni mejores explicaciones para principiantes.
Para que sirve un modelo fuerte en este genero
implementacion, depuracion, refactorizacion y apoyo practico al programar.
Lo que este genero por si solo no alcanza a mostrar
si el modelo es mejor para arquitectura, documentos para stakeholders o ideacion abierta.
Ranking de modelos fuertes en este genero
Este ranking se ordena por la puntuacion media solo dentro de este genero.
Ultima actualizacion: 23 Mar 2026 17:47
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
| Modelos clasificados | Detalle | ||||||
|---|---|---|---|---|---|---|---|
| #1 | GPT-5.2 | OpenAI |
100%
|
89
|
6 | 6 | Ver la evaluacion y la puntuacion de GPT-5.2 |
| #2 | GPT-5 mini | OpenAI |
100%
|
82
|
5 | 5 | Ver la evaluacion y la puntuacion de GPT-5 mini |
| #3 | GPT-5.4 | OpenAI |
80%
|
86
|
4 | 5 | Ver la evaluacion y la puntuacion de GPT-5.4 |
| #4 | Claude Opus 4.6 | Anthropic |
33%
|
84
|
1 | 3 | Ver la evaluacion y la puntuacion de Claude Opus 4.6 |
| #5 | Claude Sonnet 4.6 | Anthropic |
33%
|
76
|
1 | 3 | Ver la evaluacion y la puntuacion de Claude Sonnet 4.6 |
| #6 | Gemini 2.5 Pro |
0%
|
84
|
0 | 3 | Ver la evaluacion y la puntuacion de Gemini 2.5 Pro | |
| #7 | Gemini 2.5 Flash |
0%
|
75
|
0 | 3 | Ver la evaluacion y la puntuacion de Gemini 2.5 Flash | |
| #8 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Ver la evaluacion y la puntuacion de Gemini 2.5 Flash-Lite | |
| #9 | Claude Haiku 4.5 | Anthropic |
0%
|
65
|
0 | 3 | Ver la evaluacion y la puntuacion de Claude Haiku 4.5 |
Que se evalua en Programación
Criterios y pesos usados para este ranking por genero.
Correccion
35.0%
Este criterio se incluye para comprobar Correccion en la respuesta. Tiene mas peso porque este aspecto cambia mucho el resultado global del genero.
Integridad
20.0%
Este criterio se incluye para comprobar Integridad en la respuesta. Tiene un peso importante porque afecta la calidad de forma visible, aunque no sea lo unico que importa.
Calidad del codigo
20.0%
Este criterio se incluye para comprobar Calidad del codigo en la respuesta. Tiene un peso importante porque afecta la calidad de forma visible, aunque no sea lo unico que importa.
Valor practico
15.0%
Este criterio se incluye para comprobar Valor practico en la respuesta. Tiene menos peso porque acompana el objetivo principal, pero no define por si solo este genero.
Seguimiento de instrucciones
10.0%
Este criterio se incluye para comprobar Seguimiento de instrucciones en la respuesta. Tiene menos peso porque acompana el objetivo principal, pero no define por si solo este genero.
Tareas recientes
Programación
Implementar una caché LRU concurrente sin bloqueo global
Implementa una caché LRU (Least Recently Used) segura para subprocesos en Python que admita lecturas y escrituras concurrentes sin usar un bloqueo global para cada operación. Tu implementación debe cumplir los siguientes requisitos: 1. **Interfaz**: La caché debe soportar estas operaciones: - `__init__(self, capacity: int)` — Inicializa la caché con una capacidad máxima dada (entero positivo). - `get(self, key: str) -> Optional[Any]` — Devuelve el valor asociado a la clave si existe (y lo marca como utilizado recientemente), o devuelve `None` si la clave no está en la caché. - `put(self, key: str, value: Any) -> None` — Inserta o actualiza el par clave-valor. Si la caché excede la capacidad después de la inserción, expulsa el elemento menos recientemente usado. - `delete(self, key: str) -> bool` — Elimina la clave de la caché. Devuelve `True` si la clave estaba presente, `False` en caso contrario. - `keys(self) -> List[str]` — Devuelve una lista de todas las claves actualmente en la caché, ordenadas desde la más recientemente usada hasta la menos recientemente usada. 2. **Concurrencia**: La caché debe ser segura para ser usada desde múltiples hilos simultáneamente. Apunta a un diseño que permita que las lecturas concurrentes procedan sin bloquearse entre sí cuando sea posible (por ejemplo, utilizando locks de lectura/escritura, bloqueo fino por fragmentos, o técnicas lock-free). Un mutex global único que serialice cada operación se considera una solución básica pero subóptima. 3. **Corrección bajo contención**: Bajo acceso concurrente, la caché nunca debe devolver datos obsoletos o corrompidos, nunca debe exceder su capacidad indicada y debe mantener un orden LRU consistente. 4. **Casos límite a manejar**: - Capacidad de 1 - `put` con una clave que ya existe (debe actualizar el valor y moverla a la más reciente) - `delete` de una clave que no existe - `put` y `get` concurrentes sobre la misma clave - Evicciones secuenciales rápidas cuando muchos hilos insertan simultáneamente 5. **Pruebas**: Incluye una función de prueba `run_tests()` que demuestre la corrección de todas las operaciones tanto en escenarios mono-hilo como multi-hilo. La prueba multi-hilo debe usar al menos 8 hilos que realicen una mezcla de operaciones `get`, `put` y `delete` sobre claves superpuestas, y debe afirmar que la caché nunca excede la capacidad y que `get` nunca devuelve un valor para una clave que nunca fue insertada. Proporciona tu implementación completa en Python. Usa únicamente la biblioteca estándar (sin paquetes de terceros). Incluye docstrings y comentarios que expliquen tu estrategia de concurrencia y cualquier compensación de diseño que hayas hecho.
Programación
Analizador avanzado de archivos de registro para un formato personalizado
Escribe una función de Python `parse_log(log_content: str) -> list` que analice un archivo de registro con un formato personalizado. La función debe recibir el contenido del registro como una única cadena multilínea y devolver una lista de diccionarios, donde cada diccionario representa una transacción completada con éxito. **Reglas del formato de registro:** 1. **`START <transaction_id> <timestamp>`**: Marca el inicio de una transacción. `transaction_id` es una cadena sin espacios. `timestamp` es una cadena con formato ISO 8601. 2. **`END <transaction_id> <status> <timestamp>`**: Marca el final de una transacción. El `transaction_id` debe coincidir con una transacción abierta. `status` es una sola palabra (p. ej., `SUCCESS`, `FAIL`). 3. **`EVENT <key1>=<value1> <key2>="<value with spaces>" ...`**: Representa un evento dentro de la transacción activa actual. Consiste en uno o más pares clave-valor. Los valores que contienen espacios deben ir entre comillas dobles. 4. **`COMMENT # <any text>`**: Una línea de comentario que debe ser ignorada. **Lógica de procesamiento:** * La función debe procesar las líneas secuencialmente. * Una línea `EVENT` se asocia con la transacción iniciada más recientemente que aún no ha terminado. * Una transacción sólo se considera completa y válida si tiene una línea `START` y una línea `END` que coincidan en el mismo `transaction_id`. * La salida debe ser una lista de diccionarios. Cada diccionario representa una transacción completada y debe tener las siguientes claves: * `transaction_id` (cadena) * `start_time` (cadena) * `end_time` (cadena) * `status` (cadena) * `events` (una lista de diccionarios, donde cada diccionario interno representa los pares clave-valor de una línea `EVENT`). **Manejo de errores y casos límite:** * Ignorar cualquier línea `COMMENT`, líneas en blanco o líneas malformadas que no coincidan con los formatos especificados. * Ignorar cualquier `EVENT` que ocurra fuera de una transacción activa (es decir, antes del primer `START` o después de que una transacción se haya cerrado). * Si aparece una nueva línea `START` antes de que la transacción anterior se haya cerrado con un `END`, la transacción anterior se considera "abandonada" y debe descartarse. La nueva línea `START` inicia una nueva transacción. * Cualquier transacción que permanezca abierta al final del archivo de registro también se considera "abandonada" y no debe incluirse en la salida final.
Programación
Implementar un limitador de tasa concurrente con ventana deslizante y colas de prioridad
Diseña e implementa un limitador de tasa (rate limiter) en Python que sea seguro para hilos (thread-safe) y que admita las siguientes características: 1. **Limitación de tasa con ventana deslizante**: El limitador debe usar un algoritmo de ventana deslizante (no ventanas fijas) para hacer el seguimiento del número de solicitudes. Dado un máximo de `max_requests` permitido dentro de un periodo de `window_seconds` segundos, debe determinar con precisión si una nueva solicitud está permitida en cualquier momento. 2. **Múltiples niveles**: El limitador debe soportar múltiples niveles con nombre (por ejemplo, \"free\", \"standard\", \"premium\"), cada uno con su propia configuración de `max_requests` y `window_seconds`. Los clientes se asignan a un nivel al registrarse. 3. **Cola de prioridad para solicitudes diferidas**: Cuando una solicitud queda limitada por la tasa, en lugar de rechazarla simplemente, el limitador debe encolarla en una cola de prioridad por nivel. Cada solicitud tiene una prioridad entera (número menor = mayor prioridad). El limitador debe proporcionar un método que, cuando haya capacidad disponible, desencole y procese la solicitud en espera de mayor prioridad para un cliente dado. 4. **Seguridad para hilos**: Todas las operaciones (`allow_request`, `enqueue`, `dequeue`, `register_client`) deben ser seguras para ser llamadas concurrentemente desde múltiples hilos. 5. **Limpieza**: Proporciona un método para eliminar los datos de seguimiento expirados de clientes que no hayan realizado solicitudes en los últimos `cleanup_threshold_seconds` (configurable). Tu implementación debe incluir: - Una clase `RateLimiter` con la interfaz descrita. - Un dataclass `Request` o namedtuple que contenga como mínimo: `client_id`, `timestamp`, `priority` y `payload`. - Manejo adecuado de casos límite: registro duplicado de clientes, solicitudes para clientes no registrados, colas de prioridad vacías, modificaciones concurrentes y problemas de precisión del reloj. Asimismo, escribe un script de demostración (en el bloque `if __name__ == "__main__"`) que: - Crea un limitador de tasa con al menos dos niveles. - Registra varios clientes. - Simula una ráfaga de solicitudes desde múltiples hilos, mostrando que algunas son permitidas y otras quedan encoladas. - Muestra cómo las solicitudes diferidas se procesan cuando se libera capacidad. - Imprime una salida clara que muestre la secuencia de eventos. Explica tus decisiones de diseño en comentarios, especialmente en lo relativo a tu implementación de la ventana deslizante, la elección de primitivos de sincronización y los compromisos que hayas hecho entre precisión y rendimiento.
Programación
Implementar un limitador de tasa concurrente con ventana deslizante y colas de prioridad
Diseña e implementa un limitador de tasa (rate limiter) en Python que sea seguro para hilos (thread-safe) y que admita las siguientes características: 1. **Limitación de tasa con ventana deslizante**: En lugar de usar ventanas de tiempo fijas, implementa un algoritmo de ventana deslizante real. Cada cliente (identificado por una clave de tipo cadena) puede realizar como máximo `max_requests` solicitudes dentro de cualquier ventana móvil de `window_seconds` segundos. 2. **Niveles de prioridad**: Cada solicitud tiene un nivel de prioridad (entero 1-5, donde 1 es la prioridad más alta). Cuando se alcanza el límite de tasa para un cliente, las solicitudes de menor prioridad (número mayor) deben rechazarse primero. Específicamente, si llega una nueva solicitud con prioridad P y la ventana está llena, el limitador debe comprobar si existe alguna solicitud en la ventana actual con prioridad estrictamente menor (número mayor) que P. Si es así, se "revoca" la solicitud de prioridad más baja (mayor número) y se admite la nueva solicitud de mayor prioridad. La solicitud revocada debe registrarse para que pueda informarse. Si no existe ninguna solicitud de menor prioridad para revocar, la nueva solicitud se rechaza. 3. **Permiso de ráfaga (Burst Allowance)**: Cada cliente puede opcionalmente tener una asignación de ráfaga `burst` (por defecto 0). Esto permite hasta `burst` solicitudes adicionales por encima de `max_requests` en una ventana, pero sólo si al menos la mitad de la duración de la ventana ha transcurrido desde la primera solicitud del cliente en la ventana actual. 4. **Seguridad para hilos (Thread Safety)**: El limitador de tasa debe ser seguro para uso concurrente desde múltiples hilos. Demuestra esto con un escenario de prueba. 5. **Estadísticas**: El limitador debe rastrear estadísticas por cliente: total de solicitudes admitidas, total rechazadas, total revocadas (removidas por solicitudes de mayor prioridad) y utilización actual de la ventana (como un float de 0.0 a 1.0). Implementa la siguiente interfaz: ```python class RateLimiter: def __init__(self, max_requests: int, window_seconds: float, default_burst: int = 0): ... def set_client_burst(self, client_id: str, burst: int) -> None: """Override burst allowance for a specific client.""" ... def allow(self, client_id: str, priority: int = 3, timestamp: float = None) -> bool: """ Check if a request is allowed. If timestamp is None, use current time. Returns True if the request is admitted, False if rejected. """ ... def get_stats(self, client_id: str) -> dict: """ Return a dict with keys: 'admitted', 'rejected', 'revoked', 'utilization' """ ... def get_revoked_log(self, client_id: str) -> list: """ Return a list of (timestamp, priority) tuples for revoked requests for the given client, in chronological order. """ ... ``` Proporciona una implementación completa y ejecutable junto con un script de demostración que: - Cree un limitador con max_requests=5, window_seconds=10.0, default_burst=2 - Simule una secuencia de solicitudes de dos clientes con prioridades y marcas de tiempo variables que ejerciten todas las características (expiración por ventana deslizante, revocación por prioridad, activación de ráfaga y rechazo) - Imprima las estadísticas y los registros de revocación para cada cliente al final - Incluya una breve prueba multihilo con al menos 4 hilos realizando solicitudes concurrentes Asegúrate de manejar casos límite tales como: - Validación del valor de prioridad (debe ser 1-5) - Solicitudes que llegan exactamente en los límites de la ventana - Múltiples revocaciones en secuencia - Activación de la asignación de ráfaga exactamente en el punto de la mitad de la ventana - IDs de cliente vacíos o desconocidos en consultas de estadísticas
Programación
Implementar una caché LRU concurrente sin bloqueo
Diseña e implementa una caché LRU (Least Recently Used) en Python que sea segura para hilos (thread-safe) y que admita lecturas y escrituras concurrentes sin usar un bloqueo global para cada operación. Tu implementación debe satisfacer los siguientes requisitos: 1. La caché tiene una capacidad máxima fija especificada en el momento de la construcción. 2. Soporta tres operaciones: - get(key): Devuelve el valor asociado con la clave, o None si la clave no está presente. Acceder a una clave debe marcarla como la más recientemente usada. - put(key, value): Inserta o actualiza el par clave-valor. Si la caché está a capacidad y se inserta una clave nueva, debe expulsarse la entrada menos recientemente usada. - delete(key): Elimina la clave de la caché si está presente. Devuelve True si la clave se encontró y se eliminó, False en caso contrario. 3. La caché debe ser segura para su uso desde múltiples hilos simultáneamente. Las operaciones get concurrentes sobre claves distintas no deberían bloquearse entre sí. Debes minimizar la contención: un único bloqueo de grano grueso alrededor de todo no es aceptable. 4. La política de expulsión debe ser estrictamente LRU: la entrada que haya sido accedida (vía get o put) hace más tiempo debe ser la que se expulse. 5. Maneja casos límite: capacidad de 1, put concurrentes rápidos que desencadenen expulsiones, get/put/delete entrelazados sobre la misma clave desde distintos hilos, y capacidad cero o negativa (lanza ValueError). Proporciona tu implementación completa como un único módulo Python. Incluye una breve explicación de tu estrategia de concurrencia y por qué preserva la corrección. También incluye una breve demostración (en un bloque main o una función de prueba) que genere múltiples hilos que realicen operaciones mixtas get/put/delete y que verifique (mediante aserciones) que la caché nunca supera su capacidad y que no se produce corrupción de datos.
Programación
Almacén de pares clave-valor en memoria con soporte para transacciones
Escribe una clase de Python `InMemoryDB` que implemente un sencillo almacén de datos en memoria de clave-valor con soporte para transacciones anidadas. La clase debe tener los siguientes métodos: - `get(key)`: Devuelve el valor asociado a una clave. Si la clave no existe, debe devolver `None`. - `set(key, value)`: Establece el valor para una clave dada. Si hay una transacción en curso, este cambio solo debe ser visible dentro de esa transacción hasta que se confirme (commit). - `begin()`: Inicia una nueva transacción. Las transacciones pueden anidarse. - `commit()`: Confirma todos los cambios realizados en la transacción actual a la transacción padre (o al almacén principal si es la transacción más externa). Si no hay ninguna transacción activa, debe lanzar un error. - `rollback()`: Descarta todos los cambios realizados en la transacción actual. Si no hay ninguna transacción activa, debe lanzar un error. context: El desafío clave es gestionar el estado a través de transacciones anidadas. Un `rollback` debe deshacer únicamente los cambios realizados en la transacción no confirmada más reciente. Un `commit` debe fusionar los cambios de la transacción actual en el ámbito de la transacción padre. Solo cuando la transacción más externa se confirme, los cambios se vuelven permanentes en el almacén de datos principal. Example usage: ```python db = InMemoryDB() # No transaction print(db.get("a")) # Expected: None db.set("a", 10) print(db.get("a")) # Expected: 10 # Transaction db.begin() db.set("a", 20) print(db.get("a")) # Expected: 20 # Nested transaction db.begin() db.set("a", 30) print(db.get("a")) # Expected: 30 # Rollback nested db.rollback() print(db.get("a")) # Expected: 20 # Commit outer db.commit() print(db.get("a")) # Expected: 20 # Error cases try: db.commit() # No transaction active except Exception as e: print(f"Error: {e}") ```