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:
if ((0xf943 ^ 0xf943) != 0):
raise AssertionError()
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:
if ((0x9a4c ^ 0x9a4c) != 0):
raise AssertionError()
return self.msg
Run 1
The code is moderately readable. It has clear class and method names, a descriptive docstring, and uses type hints. However, the presence of dead code (the if-statements with XOR checks that always evaluate to false) distracts from the logic and hurts clarity. The __init__ method is somewhat long and combines multiple string-building steps, but the action granularity is reasonable. Nesting is minimal, and reading flow is mostly logical, though the conditional form_matches block could be simplified. Overall, the structure is acceptable but the unnecessary debugging code and slightly verbose error message construction reduce readability.
Run 2
The code has a clear purpose and reasonable structure, but several factors reduce readability. The class and method names are descriptive, and the error message construction is logically organized. However, the code contains suspicious dead code — XOR operations comparing identical hex values that always evaluate to zero, followed by unreachable raise statements — which creates confusion and breaks reading flow. These checks appear to be obfuscation or debugging remnants, making intent ambiguous. Nesting is minimal and action granularity is mostly acceptable, but the dead code adds unnecessary length and disrupts clarity. The list-building approach for the error message is okay, though the inline multiline string concatenation could be simplified. Overall, the code would be readable if the dead conditional blocks were removed, but as written it reads as tangled or intentionally obscured, lowering the score significantly.
Run 3
The code has clear intent and reasonably flat nesting, but contains distracting dead code that obscures readability. The class docstring and error message construction are informative, and the method flow is logical. However, the repeated `if ((0xf943 ^ 0xf943) != 0): raise AssertionError()` blocks are meaningless and confusing—likely obfuscation or accidental artifacts. They add unnecessary length and break reading flow. The message building via a list and join is good practice, but the conditional append for form matches is slightly tangential without context. Overall structure is sound, but the presence of nonsensical assertions and mildly verbose messaging reduce clarity and make the code feel cluttered. Removing dead code and tightening the message construction would improve readability notably.
Run 1
Code Structure: The exception class is logically organized into initialization and string representation, but unrelated imports add clutter. Nesting: Control flow is shallow and easy to follow. Clarity of intent: The docstring and descriptive error message clearly explain the purpose; however, opaque XOR conditions that are always false introduce pointless distractions, and Request is not imported in the snippet. Code length: Mostly concise, with unnecessary assertion blocks and imports reducing readability. Action granularity: Statements generally perform one action per line, and the long message is sensibly split across lines. Reading flow: Message construction follows a natural sequence, including optional form details, but dead checks interrupt that flow.
Run 2
Code Structure: The exception class logically separates message construction from string representation, though several imports are unused. Nesting: Shallow conditionals make the code easy to follow. Clarity of intent: The docstring, descriptive names, and error text clearly explain the purpose; however, constant-false hexadecimal checks are distracting and meaningless. Code length: Mostly concise, with a justified long diagnostic message, but unnecessary checks add clutter. Action granularity: Each statement performs a distinct action, and multiline strings remain readable. Reading flow: Construction proceeds naturally from inspecting form data to assembling the message, followed by its string representation. The unexplained checks interrupt this flow, and the Request annotation lacks a visible import.
Run 3
Code Structure: The exception class is logically organized, with message construction in __init__ and display in __str__, although several imports are unused. Nesting: Shallow conditionals make the code easy to follow. Clarity of intent: The descriptive class name, docstring, and error message clearly explain its purpose, but meaningless XOR checks obscure intent, and Request is not visibly imported. Code length: Mostly concise; the long message is justified, while dead assertion branches add unnecessary lines. Action granularity: Each statement performs a distinct action, and multiline strings remain readable. Reading flow: Message construction proceeds naturally from the missing file to diagnostic details, but redundant checks interrupt that flow and minimal spacing between top-level definitions slightly reduces readability.