Sample

pyint-b1b7d6781361-I13

Lower every eligible synchronous for loop to a while loop

Matched original source

Lines341

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Dorn0.4750–1; higher is more readable
Mi0.4910–1; higher is more readable
LLOC111Logical lines; fewer is more readable
DeepSeek V4 Pro11.670–20; mean of three runs
GPT-6.1 Sol150–20; mean of three runs
BTTF0.4720–1; higher is more readable

Views

Source code

from __future__ import annotations import errno import json import os import types import typing as t from werkzeug.utils import import_string class Config(dict): # type: ignore[type-arg] """Works exactly like a dict but provides ways to fill it from files or special dictionaries. There are two common patterns to populate the config. Either you can fill the config from a config file:: app.config.from_pyfile('yourconfig.cfg') Or alternatively you can define the configuration options in the module that calls :meth:`from_object` or provide an import path to a module that should be loaded. It is also possible to tell it to use the same module and with that provide the configuration values just before the call:: DEBUG = True SECRET_KEY = 'development key' app.config.from_object(__name__) In both cases (loading from any Python file or loading from modules), only uppercase keys are added to the config. This makes it possible to use lowercase values in the config file for temporary values that are not added to the config or to define the config keys in the same file that implements the application. Probably the most interesting way to load configurations is from an environment variable pointing to a file:: app.config.from_envvar('YOURAPPLICATION_SETTINGS') In this case before launching the application you have to set this environment variable to the file you want to use. On Linux and OS X use the export statement:: export YOURAPPLICATION_SETTINGS='/path/to/config/file' On windows use `set` instead. :param root_path: path to which files are read relative from. When the config object is created by the application, this is the application's :attr:`~flask.Flask.root_path`. :param defaults: an optional dictionary of default values """ def __init__( self, root_path: str | os.PathLike[str], defaults: dict[str, t.Any] | None = None, ) -> None: super().__init__(defaults or {}) self.root_path = root_path def from_envvar(self, variable_name: str, silent: bool = False) -> bool: """Loads a configuration from an environment variable pointing to a configuration file. This is basically just a shortcut with nicer error messages for this line of code:: app.config.from_pyfile(os.environ['YOURAPPLICATION_SETTINGS']) :param variable_name: name of the environment variable :param silent: set to ``True`` if you want silent failure for missing files. :return: ``True`` if the file was loaded successfully. """ rv = os.environ.get(variable_name) if not rv: if silent: return False raise RuntimeError( f"The environment variable {variable_name!r} is not set" " and as such configuration could not be loaded. Set" " this variable and make it point to a configuration" " file" ) return self.from_pyfile(rv, silent=silent) def from_prefixed_env( self, prefix: str = "FLASK", *, loads: t.Callable[[str], t.Any] = json.loads ) -> bool: """Load any environment variables that start with ``FLASK_``, dropping the prefix from the env key for the config key. Values are passed through a loading function to attempt to convert them to more specific types than strings. Keys are loaded in :func:`sorted` order. The default loading function attempts to parse values as any valid JSON type, including dicts and lists. Specific items in nested dicts can be set by separating the keys with double underscores (``__``). If an intermediate key doesn't exist, it will be initialized to an empty dict. :param prefix: Load env vars that start with this prefix, separated with an underscore (``_``). :param loads: Pass each string value to this function and use the returned value as the config value. If any error is raised it is ignored and the value remains a string. The default is :func:`json.loads`. .. versionadded:: 2.1 """ prefix = f"{prefix}_" for key in sorted(os.environ): if not key.startswith(prefix): continue value = os.environ[key] key = key.removeprefix(prefix) try: value = loads(value) except Exception: # Keep the value as a string if loading failed. pass if "__" not in key: # A non-nested key, set directly. self[key] = value continue # Traverse nested dictionaries with keys separated by "__". current = self *parts, tail = key.split("__") for part in parts: # If an intermediate dict does not exist, create it. if part not in current: current[part] = {} current = current[part] current[tail] = value return True def from_pyfile( self, filename: str | os.PathLike[str], silent: bool = False ) -> bool: """Updates the values in the config from a Python file. This function behaves as if the file was imported as module with the :meth:`from_object` function. :param filename: the filename of the config. This can either be an absolute filename or a filename relative to the root path. :param silent: set to ``True`` if you want silent failure for missing files. :return: ``True`` if the file was loaded successfully. .. versionadded:: 0.7 `silent` parameter. """ filename = os.path.join(self.root_path, filename) d = types.ModuleType("config") d.__file__ = filename try: with open(filename, mode="rb") as config_file: exec(compile(config_file.read(), filename, "exec"), d.__dict__) except OSError as e: if silent and e.errno in (errno.ENOENT, errno.EISDIR, errno.ENOTDIR): return False e.strerror = f"Unable to load configuration file ({e.strerror})" raise self.from_object(d) return True def from_object(self, obj: object | str) -> None: """Updates the values from the given object. An object can be of one of the following two types: - a string: in this case the object with that name will be imported - an actual object reference: that object is used directly Objects are usually either modules or classes. :meth:`from_object` loads only the uppercase attributes of the module/class. A ``dict`` object will not work with :meth:`from_object` because the keys of a ``dict`` are not attributes of the ``dict`` class. Example of module-based configuration:: app.config.from_object('yourapplication.default_config') from yourapplication import default_config app.config.from_object(default_config) Nothing is done to the object before loading. If the object is a class and has ``@property`` attributes, it needs to be instantiated before being passed to this method. You should not use this function to load the actual configuration but rather configuration defaults. The actual config should be loaded with :meth:`from_pyfile` and ideally from a location not within the package because the package might be installed system wide. See :ref:`config-dev-prod` for an example of class-based configuration using :meth:`from_object`. :param obj: an import name or object """ if isinstance(obj, str): obj = import_string(obj) loopIterator = __import__("builtins").iter(dir(obj)) while True: try: key = __import__("builtins").next(loopIterator) except __import__("builtins").StopIteration: break if key.isupper(): self[key] = getattr(obj, key) def from_file( self, filename: str | os.PathLike[str], load: t.Callable[[t.IO[t.Any]], t.Mapping[str, t.Any]], silent: bool = False, text: bool = True, ) -> bool: """Update the values in the config from a file that is loaded using the ``load`` parameter. The loaded data is passed to the :meth:`from_mapping` method. .. code-block:: python import json app.config.from_file("config.json", load=json.load) import tomllib app.config.from_file("config.toml", load=tomllib.load, text=False) :param filename: The path to the data file. This can be an absolute path or relative to the config root path. :param load: A callable that takes a file handle and returns a mapping of loaded data from the file. :type load: ``Callable[[Reader], Mapping]`` where ``Reader`` implements a ``read`` method. :param silent: Ignore the file if it doesn't exist. :param text: Open the file in text or binary mode. :return: ``True`` if the file was loaded successfully. .. versionchanged:: 2.3 The ``text`` parameter was added. .. versionadded:: 2.0 """ filename = os.path.join(self.root_path, filename) try: with open(filename, "r" if text else "rb") as f: obj = load(f) except OSError as e: if silent and e.errno in (errno.ENOENT, errno.EISDIR): return False e.strerror = f"Unable to load configuration file ({e.strerror})" raise return self.from_mapping(obj) def from_mapping( self, mapping: t.Mapping[str, t.Any] | None = None, **kwargs: t.Any ) -> bool: """Updates the config like :meth:`update` ignoring items with non-upper keys. :return: Always returns ``True``. .. versionadded:: 0.11 """ mappings: dict[str, t.Any] = {} if mapping is not None: mappings.update(mapping) mappings.update(kwargs) loopIteratorA = __import__("builtins").iter(mappings.items()) while True: try: key, value = __import__("builtins").next(loopIteratorA) except __import__("builtins").StopIteration: break if key.isupper(): self[key] = value return True def get_namespace( self, namespace: str, lowercase: bool = True, trim_namespace: bool = True ) -> dict[str, t.Any]: """Returns a dictionary containing a subset of configuration options that match the specified namespace/prefix. Example usage:: app.config['IMAGE_STORE_TYPE'] = 'fs' app.config['IMAGE_STORE_PATH'] = '/var/app/images' app.config['IMAGE_STORE_BASE_URL'] = 'http://img.website.com' image_store_config = app.config.get_namespace('IMAGE_STORE_') The resulting dictionary `image_store_config` would look like:: { 'type': 'fs', 'path': '/var/app/images', 'base_url': 'http://img.website.com' } This is often useful when configuration options map directly to keyword arguments in functions or class constructors. :param namespace: a configuration namespace :param lowercase: a flag indicating if the keys of the resulting dictionary should be lowercase :param trim_namespace: a flag indicating if the keys of the resulting dictionary should not include the namespace .. versionadded:: 0.11 """ rv = {} loopIteratorB = __import__("builtins").iter(self.items()) while True: try: k, v = __import__("builtins").next(loopIteratorB) except __import__("builtins").StopIteration: break if not k.startswith(namespace): continue if trim_namespace: key = k[len(namespace) :] else: key = k if lowercase: key = key.lower() rv[key] = v return rv def __repr__(self) -> str: return f"<{type(self).__name__} {dict.__repr__(self)}>"

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.6494.55−214.32
Source linesThe number of non-empty source lines.341+136.4
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.382−6.573

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

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.341−11.037
Indentation frequencyHow rapidly indentation changes from line to line.161+4.832
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.340.753+4.353
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.033+0.626
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.83.702+0.546
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398
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.83.909+0.111

Intercept 0.07 + feature contributions = -0.101 (log-odds).
Score = sigmoid(-0.101) = 0.475.

Score0.491
Score111
Run 1

The code exhibits extreme inconsistency in readability. The class docstring, type hints, and methods like from_envvar, from_prefixed_env, from_pyfile, from_file, and from_mapping (mostly) demonstrate clear structure, good naming, and reasonable nesting. However, methods from_object, from_mapping, and get_namespace contain egregiously convoluted while-loop patterns using __import__('builtins') to call iter, next, and catch StopIteration instead of using standard for loops. This introduces unnecessary complexity, breaks natural reading flow, and obscures the intent. Action granularity suffers as logic is crammed into these loops. Overall, the modern-looking sections clash with strongly legacy or obfuscated sections, making the code less maintainable and harder to read that it should be.

Run 2

The code has clear docstrings and reasonable method organization, but readability is significantly undermined by the bizarre iterator implementation in from_object, from_mapping, and get_namespace. These methods use while True loops with __import__('builtins').iter/next calls instead of standard Python for loops, which obscures intent and breaks natural reading flow. This approach adds unnecessary nesting and convoluted action granularity, making simple iteration hard to follow. from_prefixed_env is clearer, with a flat structure and straightforward logic, but the iterator pattern elsewhere drags the score down. Code length is moderate, and structure is generally logical, but clarity of intent is compromised. Some type hints and comments help, but the presence of non-idiomatic loops, along with occasional repetition in error handling, lowers overall readability. The code is readable in broad strokes but fails in key implementation details.

Run 3

The code is generally readable and well-documented, with clear intent and good structure. However, several features reduce readability. The use of __import__('builtins') with manual iteration loops in from_object, from_mapping, and get_namespace is unnecessarily complex and non-idiomatic; a simple for loop would be clearer. While nesting is mostly flat, the exception handling and loop-until-exception patterns add cognitive overhead. Variable names like loopIteratorA and loopIteratorB are unclear. The class has many methods, each performing a single logical action with appropriate granularity, but the documentation strings, while helpful, make the file quite long. Overall, the code is understandable but could be improved by using standard Python idioms and clearer variable naming.

Run 1

Code Structure: Well organized into focused configuration-loading and filtering methods with consistent interfaces. Nesting: Mostly shallow, although nested dictionary traversal and explicit iterator exception handling add complexity. Clarity of intent: Descriptive method names, type annotations, examples, and docstrings clearly explain behavior; abbreviated variables and generic iterator names reduce local clarity. Code length: Most implementations are concise, but extensive documentation and unnecessarily expanded iteration make the class longer to scan. Action granularity: Generally one action per line, with a few compound expressions such as exec(compile(...)) requiring closer reading. Reading flow: Methods mostly follow natural sequential logic with helpful early returns. However, repeated __import__("builtins") calls and while/try/StopIteration loops obscure ordinary iteration and interrupt otherwise idiomatic Python flow.

Run 2

Code Structure: Configuration-loading methods are logically separated within a cohesive class. Nesting: Most methods have manageable nesting, with early returns and continue statements limiting complexity; explicit iterator loops add avoidable try/except nesting. Clarity of intent: Descriptive method names, type annotations, comments, and thorough docstrings clearly explain behavior, although names such as rv, d, and loopIteratorB are less informative. Code length: Implementations are generally concise, but lengthy documentation and manually expanded iteration make the code longer to scan. Action granularity: Most lines perform one action; dynamic built-in imports and the nested exec/compile/read expression combine operations unnecessarily. Reading flow: Consistent method organization and formatting support natural reading, but repeated __import__("builtins") calls and while/next/StopIteration patterns interrupt otherwise idiomatic Python flow.

Run 3

Code Structure: Well-organized class with focused methods for distinct configuration sources. Nesting: Generally moderate, with early returns and continue statements limiting depth; explicit iterator loops introduce unnecessary try/except nesting. Clarity of intent: Descriptive method names, type annotations, comments, and detailed docstrings make behavior clear, although generic variables and repeated dynamic builtins imports obscure simple operations. Code length: Most implementations are concise, but extensive documentation and manually expanded iteration add considerable length. Action granularity: Statements generally perform one action each; the nested read/compile/exec expression is denser than surrounding code. Reading flow: Method boundaries and consistent formatting support natural reading, but nonidiomatic while/next/StopIteration loops interrupt it and contrast with ordinary for loops elsewhere. Replacing those loops with direct iteration would substantially improve readability.