Apply ruff formatting and safe lint fixes by kroenlein · Pull Request #1061 · CitrineInformatics/citrine-python

kroenlein · 2026-08-07T02:32:02Z

The only purpose of the PR is running all package lines through ruff so that future formatting issues do not distract from code changes.

PR Type:

Breaking change (fix or feature that would cause existing functionality to change)
Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Maintenance (non-breaking change to assist developers)

Adherence to team decisions

I have added tests for 100% coverage
I have written Numpy-style docstrings for every method and class.
I have communicated the downstream consequences of the PR to others.
I have bumped the version in __version__.py

…igial-test-fields [v5.0] Remove vestigial experimental fields from test fixture

Ran `ruff format` and `ruff check --fix` (safe fixes only, line-length 99) over all Python files in src/ and tests/. Resolved conflicts with the project's flake8 configuration: - Disabled RUF100 during the fix so noqa comments flake8 relies on (D-codes, E501, W505) are preserved. - Hand-wrapped 8 f-strings that exceeded 99 chars after .format() -> f-string conversion. - Added E203 to the flake8 ignore list (standard ruff/black slice-spacing exception). Fixed two autofixes that would have broken the test suite: - Restored the load-bearing import order in tests/utils/fakes/__init__.py (marked # isort: skip_file) to avoid a circular import. - Restored the pytest fixture import in tests/serialization/test_scorers.py (marked # noqa: F401). flake8 is clean and all 1237 tests pass. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>

anoto-moniz · 2026-08-19T14:54:48Z

+            | LinkByUID
+            | Sequence[PropertyTemplate | LinkByUID | BaseBounds | None]
+        ]
+        | None = None,


I continue to think multi-line type definitions in the middle of a function definition are the work of the devil. But I'm not sure a super long line is much better...

Follow-up to the ruff-formatting pass, addressing Austin's review feedback and applying the same fixes to unflagged instances of each concern type. - Add [tool.ruff] config: skip-magic-trailing-comma (collapses single-line collections instead of exploding them) with isort.split-on-trailing-comma disabled for compatibility. - Convert .format() calls on string literals to f-strings. - Drop orphaned `# pragma: no cover` comments left after `pass` removal. - Refactor split-operand/wrapped asserts to keep operands together (extract locals, loop over cases, lambda accessors) and move comments that forced line wraps above their expressions. - gemtables/variables.py: extract the repeated ternary into a module-level `_build_attribute_constraints` helper and hoist the duplicated `_AttributeType`/`_ObjectType`/`_ConstraintType` aliases to module scope. - Restore correct (separate) LinkOrElse instances in the template property definitions; shared Property descriptors break serialization-path assignment. - validate_type: raise ValueError instead of bare Exception. - Cover PvA __iter__ explicitly after switching next(iter(...)) reads to []. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

anoto-moniz · 2026-09-02T14:41:59Z

@kroenlein With the exception of #1061 (comment), this looks great! Once you get that squared away, I'll give you a stamp, and update my workflow to use uv ruff.

anoto-moniz · 2026-09-10T13:34:39Z



+def _attr_tuple(tempate_class: Serializable) -> Serializable:
+    tuple_form = SpecifiedMixedList([LinkOrElse(tempate_class), Optional(Object(BaseBounds))])


Just because this is an area I'm less familiar with: will the second type always be BaseBounds? Or should that be an optional parameter, or should something about the function's name indicate that will be used?

If we wanted to be super careful, we'd check that the bounds type aligned with the bounds type referenced in the template, but that's no always possible given that the template is a LinkOrElse. So this is guaranteed correct and don't require additional logic.

anoto-moniz

My only remaining comment is a clarification, so no need to hold up over that. Thanks for going through all this! I'll update my local tooling to ensure I don't accidentally reverse it.

kroenlein and others added 2 commits August 6, 2026 09:09

Merge pull request #1059 from CitrineInformatics/maintain/remove-vest…

b267e8f

…igial-test-fields [v5.0] Remove vestigial experimental fields from test fixture

kroenlein marked this pull request as ready for review August 7, 2026 02:36

kroenlein requested a review from a team as a code owner August 7, 2026 02:36

anoto-moniz force-pushed the release/5.0 branch from b267e8f to 7bcc6e3 Compare August 7, 2026 15:16

Base automatically changed from release/5.0 to main August 7, 2026 15:19

Merge branch 'main' into maintain/ruff-formatting

6b3633f

github-advanced-security Bot found potential problems Aug 17, 2026

View reviewed changes

Comment thread tests/_util/test_functions.py Fixed

Satisfying profound overreaction by CodeQL sanitization false positive

e5d016b

Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>