Skip to content

feat!: remove the seven deprecated exception aliases (07lk.10) - #1573

Merged
dgunning merged 1 commit into
mainfrom
feat/07lk10-remove-exception-aliases
Oct 17, 2026
Merged

dgunning merged 1 commit into
mainfrom
feat/07lk10-remove-exception-aliases

Conversation

@dgunning

Copy link
Copy Markdown
Owner

What this changes

Removes the seven exception names that were deprecated throughout 5.x: StatementNotFound, NoCompanyFactsFound, SECFilingNotFoundError, InvalidDateException, IdentityNotSetException, TooManyRequestsException and DataObjectException. Importing one now raises ImportError. Their replacements in edgar.exceptions have existed since 5.48.0. This finishes the alias-removal half of the 07lk.10 window, which #1557 left for a separate PR.

  • The module __getattr__ shims are removed from edgar.core, edgar.dates, edgar.entity, edgar.entity.core, edgar.entity.entity_facts, edgar.httprequests, edgar.sgml.sgml_parser and edgar.xbrl.exceptions, and the names are taken out of every __all__ that listed them. Three of those __all__ entries were already flagged by ruff as undefined names (F822). DataObjectException leaves edgar.__all__.
  • edgar/_compat.py is deleted. It had no other user, and its warning text hard-codes "removed in v6.0". edgar.core's access-mode lookup is now the module __getattr__ itself, so its warning is one call level closer to the caller and its stacklevel is the default again. The EDGAR_ACCESS_MODE is documented with a timeout/connection/retry table, but nothing in the package reads it #1326 test that the warning names the caller's code still passes.
  • MCP fix: ERROR_SUGGESTIONS was keyed on three of the old names. get_error_suggestions() looks errors up by type(e).__name__, which hasn't matched those keys since 5.48.0, so those three suggestion lists were never returned there. The keys now use the canonical names.
  • The offerings eval recognised outage errors by two of the old class names, which nothing has raised since 5.48.0. It now uses the canonical names.

Part of #933 (the 6.0 exception hierarchy; that issue stays open for the CI job below).

Verification

  • Docs: docs/guides/error-handling.md and docs/upgrade/6.0.md now have a "Names removed in 6.0" table. The guide-names test checks that table in reverse: all seven must not resolve, and every other exception the guide names must. The entity-facts reference, edgar/xbrl/docs/XBRL.md and the two package CLAUDE.md files use the new names.
  • Silence check: test_removed_alias_no_longer_resolves asserts, for every module that used to resolve an old name, that it is no longer an attribute, no longer in __all__, and that from module import Name raises ImportError.
  • Changelog: changelog.d/07lk10-aliases.removed.md
  • Ground truth: all seven new names exist in the v5.48.0 tag (git show v5.48.0:edgar/exceptions.py), which is what the guide's "switch before upgrading" advice relies on.
  • hatch run test-fast: 42503 passed, 9 skipped, 1 xfailed. from edgar import * and every changed module import with no warnings under -W error::DeprecationWarning, and every remaining __all__ entry resolves. Ruff finds no new pyflakes errors in the changed files and three fewer than main.

6.0

  • This PR removes names deprecated for 6.0, and docs/upgrade/6.0.md says what users see now (ImportError) and what to use instead.

Not in this PR: removing the test-strict-errors job from .github/workflows/python-hatch-workflow.yml. That edit needs a token with workflow scope, so the maintainer will make it.

AI assistance

  • Assisted. Tool and model: Claude Code, Claude Opus 5.5

🤖 Generated with Claude Code

StatementNotFound, NoCompanyFactsFound, SECFilingNotFoundError,
InvalidDateException, IdentityNotSetException, TooManyRequestsException and
DataObjectException warned through every 5.x release since 5.48.0, where
their canonical replacements in edgar.exceptions first shipped (checked
against the v5.48.0 tag). This is the alias-removal half of the 07lk.10
window that PR #1557 left for a separate PR.

- The module __getattr__ shims go from edgar.core, edgar.dates,
  edgar.entity, edgar.entity.core, edgar.entity.entity_facts,
  edgar.httprequests, edgar.sgml.sgml_parser and edgar.xbrl.exceptions, and
  the names leave every __all__ that listed them (three of those were
  already F822 undefined-name entries). DataObjectException, a subclass that
  took a Filing, leaves edgar/__init__.py and edgar.__all__.
- edgar/_compat.py had no other user, and its message hard-codes "removed in
  v6.0", so it is deleted rather than left to mislabel a later deprecation.
  edgar.core's access-mode lookup becomes the module __getattr__ itself, one
  frame shallower, so its stacklevel returns to the settings default; the
  #1326 test that the warning blames the caller still passes.
- MCP ERROR_SUGGESTIONS was keyed on three of the old names.
  classify_error indexed them by literal, but get_error_suggestions looks up
  type(e).__name__, which has been the canonical name since 5.48.0, so
  those three suggestion lists never matched there. Keys are now canonical.
- The offerings eval matched transport failures by the old class names,
  which nothing has raised since 5.48.0; now the canonical names.
- Docs: the error-handling guide and the upgrade guide say the names were
  removed and that importing one raises ImportError; the entity-facts
  reference, XBRL.md and the two package CLAUDE.md files use the new names.
- Tests: the alias-resolves test becomes a removed-alias test (no attribute,
  not in __all__, `from m import X` raises ImportError, for every module
  that resolved it). The guide-names test now checks the "Names removed in
  6.0" table the other way round: those seven must not resolve.

hatch run test-fast: 42503 passed, 9 skipped, 1 xfailed. `from edgar import *`
and every changed module import clean under -W error::DeprecationWarning.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@dgunning
dgunning merged commit fcfe35c into main Oct 17, 2026
11 checks passed
@dgunning
dgunning deleted the feat/07lk10-remove-exception-aliases branch October 17, 2026 16:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant