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 shows mixed readability. The class has a clear docstring and logical purpose, but the message construction is fragmented with awkward string concatenations broken across lines (e.g., separate adjacent string literals and weird indentation). The __init__ method has deeply awkward formatting in the buf list and the if form_matches block, making the reading flow unnatural. The intent is understandable for an error class, but the excessive line breaks and inconsistent spacing reduce clarity. Code structure is straightforward but the nesting is shallow; however, action granularity suffers due to multi-line string concatenations that obscure the message content. Variable names are descriptive, and the logic is simple, but the formatting detracts from overall readability. The code could be improved by using triple-quoted strings or cleaner f-string formatting.
Run 2
The code is generally readable with clear class and method naming, a helpful docstring, and mostly logical structure. The long string concatenation in the error message is awkwardly formatted—some lines have poor spacing and alignment, making the intent less immediately clear. The nested conditional adds slight depth but remains manageable. The action granularity is mostly one action per line, though the append statement packs multiple string segments into one line. Overall structure is logical, but the formatting and long concatenated strings reduce clarity somewhat.
Run 3
The code has some readability issues. While the class and method structure is logical, there are several problems: string concatenation is fragmented across multiple lines in an unnatural way, with awkward spacing around string literals (e.g., `f"...files" " dictionary..."`). The `buf.append()` call has excessive indentation and broken string pieces. The `__init__` method mixes string building logic with error message construction, making the intent less clear. There are unused imports (`BaseLoader`, `RequestRedirect`, `Blueprint`, `_cv_app`, `App`). The error message construction could be simplified with cleaner string formatting. The positive aspects are the docstring and the use of clear variable names like `form_matches` and `buf`. Overall, the code works but requires effort to read due to poor formatting and unclear string assembly.
Run 1
Code Structure: The exception class is logically organized, with initialization and string conversion clearly separated, although several imports appear unused. Nesting: Only one conditional keeps the code flat and easy to follow. Clarity of intent: The descriptive class name, docstring, and error message clearly explain the purpose; Request is not defined or imported in the snippet. Code length: Concise overall, though the message construction dominates the implementation. Action granularity: Most statements perform one action, but multiple adjacent string literals on unusually spaced lines make the message harder to scan. Reading flow: Execution proceeds naturally from collecting form values to constructing the message, but inconsistent spacing and awkward formatting disrupt readability.
Run 2
Code Structure: The exception class is logically organized, with initialization and string representation clearly separated, though several imports appear unused. Nesting: A single conditional keeps the code shallow and easy to follow. Clarity of intent: The descriptive class name, docstring, and error message explain the purpose well; however, Request is not imported in the shown snippet. Code length: The implementation is compact, although the single-element buffer and final join add slight complexity. Action granularity: Statements generally perform one action each, but crowded adjacent string literals make message construction harder to parse. Reading flow: Execution follows a natural sequence from collecting form values to constructing the message, but irregular spacing and long lines interrupt readability.
Run 3
Code Structure: The exception class logically groups message construction and string representation, although several imports appear unused and Request is not visibly imported. Nesting: Only one conditional keeps the code flat and easy to follow. Clarity of intent: The descriptive class name, docstring, and error message clearly explain the purpose; buf and names are understandable in context. Code length: The implementation is compact, though using a list and joining it adds minor complexity for a mostly fixed message. Action granularity: Most statements perform one action, but long lines combining adjacent string literals obscure message assembly. Reading flow: Initialization, optional diagnostic details, and final message storage follow a natural sequence. However, excessive inline spacing, awkward string formatting, and limited separation around imports and the class reduce visual readability.