Source code
from __future__ import annotations
import ast
import collections.abc as cabc
import importlib.metadata
import inspect
import os
import platform
import re
import sys
import traceback
import typing as t
from functools import update_wrapper
from operator import itemgetter
from types import ModuleType
import click
from click.core import ParameterSource
from werkzeug import run_simple
from werkzeug.serving import is_running_from_reloader
from werkzeug.utils import import_string
from .globals import current_app
from .helpers import get_debug_flag
from .helpers import get_load_dotenv
class CertParamType(click.ParamType):
name = "path"
def __init__(self) -> None:
self.path_type = click.Path(exists=True, dir_okay=False, resolve_path=True)
def convert(
self, value: t.Any, param: click.Parameter | None, ctx: click.Context | None
) -> t.Any:
try:
import ssl
except ImportError:
raise click.BadParameter(
'Using "--cert" requires Python to be compiled with SSL support.',
ctx,
param,
) from None
try:
return self.path_type(value, param, ctx)
except click.BadParameter:
value = click.STRING(value, param, ctx).lower()
if value == "adhoc":
try:
import cryptography
except ImportError:
raise click.BadParameter(
"Using ad-hoc certificates requires the cryptography library.",
ctx,
param,
) from None
return value
obj = import_string(value, silent=True)
if isinstance(obj, ssl.SSLContext):
return obj
raise
Run 1
The code is generally readable but has some issues with action granularity and vertical density. The CertParamType class has a clear purpose with reasonable structure and flat nesting levels. Intent is mostly clear in validation flow. However, several lines combine multiple actions (e.g., import-raise statements, chained lower() calls with assignment). The conversion logic mixes error handling with type checking and import fallbacks in a compressed style. Some nesting could be flatter, particularly in the ad-hoc certificate handling section. Specific issues include unnecessary blank line after class definition, multiple statements on single lines (like `raise click.BadParameter(...) from None`), and densely packed conditional blocks. Reading flow is moderately natural but could improve with better spacing and separation of concerns between validation and conversion.
Run 2
The code is generally readable with clear intent and logical structure. It uses type hints and imports are well-organized. However, there are some issues that affect readability: multiple actions occur in a few lines, and there are some redundant/verbose parts (like the nested try-except blocks and a redundant import in CertParamType). Nesting isn't excessive but could be flattened slightly. The convert method clearly communicates its purpose, but the handling of different cert types could be better separated. Overall, it's reasonably readable but not exemplary.
Run 3
The code is generally well-structured with clear imports, proper type hints, and a logical class definition. The CertParamType class has a clear single responsibility and flat nesting in most areas. The convert method follows a natural flow: attempt path conversion, fall back to string conversion, then handle special cases. However, readability is slightly reduced by the nested try-except blocks with multiple levels of indentation, and the empty ssl import inside the try block serves only as a capability check, which is not immediately obvious. Some lines contain multiple actions (e.g., value = click.STRING(value, param, ctx).lower()), though this is minor. The docstring is missing, which would help clarify intent. The raise statement at the end without an explicit exception type relies on context and may confuse readers unfamiliar with exception handling patterns.
Run 1
Code Structure: Imports and a focused parameter-conversion class are logically organized, although many imports are unused in this snippet. Nesting: Moderate nesting, including a try/except inside a conditional within another exception handler, slightly increases reading effort. Clarity of intent: Descriptive names, type annotations, and explicit error messages make certificate validation understandable; the fallback behavior and final bare raise require closer attention. Code length: The implementation is reasonably concise, but excessive blank lines and the large import block add visual clutter. Action granularity: Statements generally perform one action per line, with readable multiline calls. Reading flow: The progression from SSL availability to file-path validation, ad-hoc certificates, and imported SSL contexts is coherent, though exception-driven fallback makes the flow less direct.
Run 2
Code Structure: A focused class cleanly separates initialization from conversion, though the extensive unrelated imports add clutter. Nesting: Several nested try/except and conditional blocks require attention, but remain manageable. Clarity of intent: Descriptive names, type annotations, and specific error messages make certificate validation understandable; the fallback sequence and final bare raise are less immediately obvious. Code length: The implementation is reasonably concise, but excess imports and blank lines reduce compactness. Action granularity: Statements generally perform one action per line, with readable multiline calls. Reading flow: Validation proceeds logically from SSL availability to a certificate path, ad-hoc mode, and an imported SSL context, although exception-driven fallback and inconsistent whitespace slightly interrupt the flow.
Run 3
Code Structure: A focused parameter-type class separates initialization from conversion, although numerous unused imports clutter this excerpt. Nesting: Nested exception handlers and conditionals add moderate depth, but early returns keep branching manageable. Clarity of intent: Descriptive names, type annotations, and specific error messages clearly convey certificate validation; the fallback from paths to special values or imported objects could benefit from a brief explanation. Code length: The implementation is reasonably concise, but excess blank lines and unrelated imports add noise. Action granularity: Statements generally perform one action per line, with readable multiline calls. Reading flow: Conversion proceeds logically through SSL availability, path validation, ad-hoc certificates, and SSL context lookup. Exception-driven fallback and the final bare raise require some additional attention.