Source code
from __future__ import annotations
import typing as t
from jinja2.loaders import BaseLoader
from werkzeug.routing import RequestRedirect
from .blueprints import Blueprint
from .globals import _cv_app
from .sansio.app import App
class DebugFilesKeyError(KeyError, AssertionError):
"""Raised from request.files during debugging. The idea is that it can
provide a better error message than just a generic KeyError/BadRequest.
"""
def __init__(self, request: Request, key: str) -> None:
form_matches = request.form.getlist(key)
buf = [
f"You tried to access the file {key!r} in the request.files"
" dictionary but it does not exist. The mimetype for the"
f" request is {request.mimetype!r} instead of"
" 'multipart/form-data' which means that no file contents"
" were transmitted. To fix this error you should provide"
' enctype="multipart/form-data" in your form.'
]
if form_matches:
names = ", ".join(repr(x) for x in form_matches)
buf.append(
"\n\nThe browser instead transmitted some file names. "
f"This was submitted: {names}"
)
self.msg = "".join(buf)
def __str__(self) -> str:
return self.msg
Run 1
The code is well-structured and readable. It uses clear imports, logical class definition, and a focused exception class with a single responsibility. The constructor builds an error message via a list of strings, which is a clean approach. Nesting is minimal (one conditional), and each line generally performs one logical action. The f-strings and multi-line string concatenation are readable, though the mixing of f-strings and plain string concatenation slightly interrupts flow. The class docstring explains intent clearly. Minor deductions: 'AssertionError' in the base classes is unusual and could confuse readers; 'form_matches' could be more descriptively named. Overall, the code is concise, well-organized, and easy to follow.
Run 2
The code has clear intent, explicit error messaging, and a logical structure with minimal nesting. The class is concise, uses type hints, and maintains one action per line. Readability is good but not excellent due to the absence of a docstring for __str__, minor inconsistencies in string formatting (mixing f-strings and concatenation), and the lack of a clear separation between building the message and assigning it. The reading flow is decent but could be improved slightly by aligning string construction or extracting helper methods. Overall, it is readable and maintainable but has small stylistic inconsistencies.
Run 3
The code is well-structured and readable. It defines a custom exception with a clear purpose: improving debug error messages for missing files in requests. The class is concise, uses type hints, and follows a logical flow—initializing error context in __init__ and presenting it via __str__. Nesting is minimal, with one conditional block. Variable names are descriptive (e.g., form_matches, buf). Action granularity is good: list building and string joining are separated clearly. The multi-line f-string concatenation improves readability despite minor visual complexity. Minor drawbacks: the error message construction could be slightly more compact, and the class name 'DebugFilesKeyError' is a bit verbose. Overall, the code is highly readable and maintainable.
Run 1
Code Structure: The exception class is logically organized, with message construction in __init__ and rendering in __str__. Nesting: Only one shallow conditional keeps complexity low. Clarity of intent: The descriptive class name, docstring, and variable names clearly explain the diagnostic purpose, although Request is not imported in the snippet and several imports are unused. Code length: The implementation is concise; most of its length is useful explanatory message text. Action granularity: Each statement performs one clear operation, and multiline string construction avoids crowded lines. Reading flow: Execution proceeds naturally from inspecting form data to constructing the message and optionally adding submitted filenames. Minor distractions include unused imports and mixing adjacent string literals with formatted strings.
Run 2
Code Structure: The exception class is logically organized, with message construction in __init__ and rendering in __str__; several unused imports add clutter. Nesting: A single conditional keeps the code shallow and easy to follow. Clarity of intent: The descriptive class name, docstring, and explicit error text clearly explain its purpose, although Request is not imported in the snippet. Code length: The implementation is compact; the lengthy message is justified by its diagnostic role. Action granularity: Statements generally perform one action each, and multiline string literals remain readable. Reading flow: Execution proceeds naturally from collecting form values to building the message and storing it, with minor readability costs from abbreviated names such as buf and x.
Run 3
Code Structure: The exception class is logically organized, with message construction in __init__ and rendering in __str__; unused imports add clutter. Nesting: Only one conditional keeps the code shallow and easy to follow. Clarity of intent: The descriptive class name, docstring, and explicit error message clearly explain its purpose, although Request is not imported in the snippet and buf is a generic name. Code length: The implementation is concise; most of its length comes from useful diagnostic text. Action granularity: Statements generally perform one action each, with no compressed multi-statement lines. Reading flow: The sequence naturally progresses from retrieving form values to building the message, adding optional details, and storing the result. Adjacent string literals require minor attention but keep long text manageable.