Sample

pyint-38c87b367c7a-I04

Replace names with deterministic minifier-style shortest identifiers

Matched original source

Lines170

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.2940–1; higher is more readable
Mi0.4270–1; higher is more readable
LLOC78Logical lines; fewer is more readable
DeepSeek V4 Pro7.670–20; mean of three runs
GPT-6.1 Sol110–20; mean of three runs
BTTF0.3480–1; higher is more readable

Views

Source code

from __future__ import annotations import importlib.metadata import typing as t from contextlib import contextmanager from contextlib import ExitStack from copy import copy from types import TracebackType from urllib.parse import urlsplit import werkzeug.test from click.testing import CliRunner from click.testing import Result from werkzeug.test import Client from werkzeug.wrappers import Request as BaseRequest from .cli import ScriptInfo from .sessions import SessionMixin class FlaskClient(Client): """Works like a regular Werkzeug test client, with additional behavior for Flask. Can defer the cleanup of the request context until the end of a ``with`` block. For general information about how to use this class refer to :class:`werkzeug.test.Client`. .. versionchanged:: 0.12 `app.test_client()` includes preset default environment, which can be set after instantiation of the `app.test_client()` object in `client.environ_base`. Basic usage is outlined in the :doc:`/testing` chapter. """ application: Flask def __init__(self, *e: t.Any, **f: t.Any) -> None: super().__init__(*e, **f) self.preserve_context = False self._new_contexts: list[t.ContextManager[t.Any]] = [] self._context_stack = ExitStack() self.environ_base = { "REMOTE_ADDR": "127.0.0.1", "HTTP_USER_AGENT": f"Werkzeug/{_get_werkzeug_version()}", } @contextmanager def a( self, *g: t.Any, **h: t.Any ) -> t.Iterator[SessionMixin]: """When used in combination with a ``with`` statement this opens a session transaction. This can be used to modify the session that the test client uses. Once the ``with`` block is left the session is stored back. :: with client.session_transaction() as session: session['value'] = 42 Internally this is implemented by going through a temporary test request context and since session handling could depend on request variables this function accepts the same arguments as :meth:`~flask.Flask.test_request_context` which are directly passed through. """ if self._cookies is None: raise TypeError( "Cookies are disabled. Create a client with 'use_cookies=True'." ) i = self.application j = i.test_request_context(*g, **h) self._add_cookies_to_wsgi(j.request.environ) with j: k = i.session_interface.open_session(i, j.request) if k is None: raise RuntimeError("Session backend did not open a session.") yield k l = i.response_class() if i.session_interface.is_null_session(k): return with j: i.session_interface.save_session(i, k, l) self._update_cookies_from_response( urlsplit(j.request.host_url).hostname or "localhost", j.request.path, l.headers.getlist("Set-Cookie"), ) def b(self, m: WSGIEnvironment) -> WSGIEnvironment: n = {**self.environ_base, **m} if self.preserve_context: n["werkzeug.debug.preserve_context"] = self._new_contexts.append return n def c( self, o: tuple[t.Any, ...], p: dict[str, t.Any] ) -> BaseRequest: p["environ_base"] = self.b(p.get("environ_base", {})) q = EnvironBuilder(self.application, *o, **p) try: return q.get_request() finally: q.close() def d( self, *r: t.Any, s: bool = False, u: bool = False, **v: t.Any, ) -> TestResponse: if r and isinstance( r[0], (werkzeug.test.EnvironBuilder, dict, BaseRequest) ): if isinstance(r[0], werkzeug.test.EnvironBuilder): w = copy(r[0]) w.environ_base = self.b(w.environ_base or {}) # type: ignore[arg-type] x = w.get_request() elif isinstance(r[0], dict): x = EnvironBuilder.from_environ( r[0], app=self.application, environ_base=self.b({}) ).get_request() else: # isinstance(args[0], BaseRequest) x = copy(r[0]) x.environ = self.b(x.environ) else: # request is None x = self.c(r, v) # Pop any previously preserved contexts. This prevents contexts # from being preserved across redirects or multiple requests # within a single block. self._context_stack.close() y = super().open( x, buffered=s, follow_redirects=u, ) y.json_module = self.application.json # type: ignore[assignment] # Re-push contexts that were preserved during the request. for z in self._new_contexts: self._context_stack.enter_context(z) self._new_contexts.clear() return y def __enter__(self) -> FlaskClient: if self.preserve_context: raise RuntimeError("Cannot nest client invocations") self.preserve_context = True return self def __exit__( self, A: type | None, B: BaseException | None, C: TracebackType | None, ) -> None: self.preserve_context = False self._context_stack.close()

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.5516.529−182.045
Source linesThe number of non-empty source lines.170+68
Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value.4.48−6.72

Intercept 8.87 + feature contributions = -111.896 (log-odds).
Score = sigmoid(-111.896) = 0.

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.171−5.018
Indentation frequencyHow rapidly indentation changes from line to line.136+3.967
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.136−2.7
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.169.818+1.964
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.85.953+0.582
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.069+0.276
Identifier layout (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names.86.982−0.019

Intercept 0.07 + feature contributions = -0.878 (log-odds).
Score = sigmoid(-0.878) = 0.294.

Score0.427
Score78
Run 1

The code structure is logical, but readability is severely degraded by poor naming conventions. Attributes and methods use single-letter or meaningless names like `a`, `b`, `c`, `d`, `e`, `f`, `g`, `h`, `i`, `j`, `k`, `l`, `m`, `n`, `o`, `p`, `q`, `r`, `s`, `u`, `v`, `w`, `x`, `y`, `z`, `A`, `B`, `C`. This makes intent ambiguous despite docstrings. Nesting is moderate but complex request-building logic in method `d` involves multiple nested branches, reducing flow. Action granularity is mostly one action per line, but dense lines with multiple operations hurt clarity. The original names likely were descriptive, and the obfuscation significantly lowers readability.

Run 2

The code has a clear structure with meaningful class and method organization, but variable names are severely degraded (single letters like 'a', 'b', 'c', 'i', 'j', 'k', 'l', 'x', 'y'), making the intent hard to understand without reading the documentation carefully. Nesting is moderate; method 'd' has some if-else branching but is not deeply nested. Multiple actions are sometimes combined on one line, reducing readability. The use of abbreviations for parameters ('e', 'f', 'g', 'h', 'm', 'o', 'p') further obscures the purpose. While docstrings clarify behavior, the variable naming is a major drawback. The flow is logical, but the poor names force extra cognitive effort. It is not unreadable due to proper organization and comments, but the variable naming significantly lowers the score.

Run 3

The code is largely unreadable due to single-letter variable names that obscure meaning, function names like 'a', 'b', 'c', 'd' that give no indication of purpose, and fragmented logic that disrupts reading flow. Type annotations are present but do not compensate for poor naming. The structure contains excessive blank lines and comments that fail to clarify intent. Nesting is moderate but the ambiguous identifiers make the flow hard to follow. The code length is moderate, but action granularity suffers from condensed operations and unclear separation of concerns. Overall, the code requires significant effort to understand and maintain.

Run 1

Code Structure: Responsibilities are separated into methods, with logical session, request, and context management. Nesting: Mostly shallow, although request-type dispatch introduces moderate nesting. Clarity of intent: Severely weakened by single-letter method, parameter, and variable names; docstrings and comments help, but references to session_transaction and args do not match the actual names. Code length: Reasonably concise for the functionality, though lengthy documentation contrasts with opaque implementations. Action granularity: Generally one action per line, making individual operations easy to follow. Reading flow: Execution proceeds naturally within methods, but cryptic identifiers and unresolved references such as EnvironBuilder and _get_werkzeug_version force readers to infer meaning or consult external context.

Run 2

Code Structure: Responsibilities are separated into methods, with coherent request, session, and context management. Nesting: Mostly shallow, although request-type dispatch adds moderate branching. Clarity of intent: The largest weakness is single-letter method and variable names, which obscure roles and require tracing operations. Docstrings and comments help, but references to session_transaction and args do not match the renamed identifiers. Code length: Reasonably concise for the functionality, though lengthy documentation contrasts with cryptic implementation names. Action granularity: Generally one action per line, with clear assignments and calls. Reading flow: Sequential operations, early exits, and try/finally support natural reading, but opaque identifiers and externally defined types interrupt comprehension.

Run 3

Code Structure: Methods separate session handling, environment preparation, request construction, and context management logically. Nesting: Mostly shallow, with manageable conditional branching in request handling. Clarity of intent: Severely weakened by single-letter method and variable names; descriptive attributes, type hints, and documentation partially compensate. Some comments and examples reference names absent from the code, creating confusion. Code length: Generally proportionate to the functionality, although the lengthy session docstring contrasts with its opaque method name. Action granularity: Most lines perform one action, with a few compact expressions combining environment construction or request preparation. Reading flow: Execution proceeds naturally within methods, but deciphering identifiers and tracing calls between a, b, c, and d repeatedly interrupts comprehension. Overall, sound organization and formatting are undermined by pervasive ambiguous naming.