chore(api): freeze 1.0 public surface; fix Fill registry-key collision#27
Merged
Conversation
The `\fill` length factory (`pytex.commands.lengths.Fill`) and the TikZ `\fill` path command (`pytex_tikz.Fill`) both registered under the single registry key `"Fill"`. The reverse lookup and the `pytex(...)` eval namespace therefore resolved to whichever module imported last (import-order-dependent), and importing both logged a "Duplicate key in registry (overwritten): Fill" warning. Rename the length factory `Fill` -> `Fill_len`, mirroring the existing `Arraystretch_len` which already dodges the `Arraystretch` table command the same way. This leaves the bare `Fill` key to the TikZ command (parallel to `Draw`) and is the least-surprising option: the in-package `_len` convention already exists, and a flat eval namespace cannot disambiguate two bare `Fill` names regardless of registry-key scheme, so renaming is the only fix that makes the lookup deterministic. A deprecated `pytex.commands.lengths.Fill` alias keeps importing and emits a DeprecationWarning. The TikZ `Fill` is unchanged. API freeze: every package already declares an explicit `__all__` (pyright validates the entries). Document the 1.0 stability contract in a README `Stability` section — the names a package exports plus the registry keys reachable from `pytex(...)`, with leading-underscore names and underscore-prefixed modules (`pytex_api._policy`, `pytex_api._compile`) marked internal. Tests: registry keys are disjoint and deterministic, a fresh dual import logs no duplicate-key warning, and the deprecated alias warns. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
1.0 prep: public-API freeze +
Fillregistry collision fixFillregistry-key collision — chosen approachpytex.commands.lengths.Fill(the rubber length\fill) andpytex_tikz.Fill(the TikZ
\fillpath command) both registered under the single registry key"Fill". Effects:tex2py/Registry.get),\iffalse{pytex(...)}\fieval namespace resolved bareFillto whichevermodule imported last,
Duplicate key in registry (overwritten): Fill.Fix: rename the length factory
Fill→Fill_len(option b — rename onesymbol + deprecation alias).
Why not option (a) namespaced keys: the
pytex(...)eval namespace is a flatdict keyed by bare name. Two distinct public callables both named
Fillcannotcoexist there unambiguously regardless of the registry-key scheme — qualifying
keys only fixes the duplicate-warning/reverse-lookup, the bare-name eval stays
ambiguous. Renaming is the only fix that makes the lookup deterministic.
Why
_len: the package already uses this exact convention —Arraystretch_lenexists precisely because
Arraystretch(thetablescommand) holds that key.Following the established convention keeps the bare
Fillkey with the TikZcommand (parallel to
Draw), and is self-justifying. A deprecatedpytex.commands.lengths.Fillmodule-level alias keeps importing and emits aDeprecationWarning(mirrors thepytex_protocolshim). The TikZFillisuntouched.
Public-API freeze
Every package already declares an explicit
__all__, and basedpyright validatesthe entries (
reportUnsupportedDunderAll), so the surface was already disciplined— no churn was needed. Added a concise
Stabilitysection to the READMEstating the 1.0 SemVer contract:
__all__, plus the registry keysreachable from
pytex(...)markers (renaming a registered factory is breaking).(
pytex_api._policy,pytex_api._compile), anything outside__all__.pytex_protocol, thelengths.Fillalias) warn and may beremoved in the next major.
Tests
Fill/Fill_lenare disjoint and deterministic,lengths.Fillalias emits aDeprecationWarning.Status
ruff format --check src tests✅ ·ruff check src tests✅basedpyright src✅ 0 errors (0/0 on CI's Python 3.13; locally 1 warning is a3.14-only artifact of the existing
\fill-3.14reportUnreachableignore — nottouched by this PR)
pytest -q✅ 910 passed, 2 skipped🤖 Generated with Claude Code