`ApiError` (via `core`) not properly exposed in __init__.py leading to poor developer experience

[StephenWithPH]

Checklist

• I have looked into the Readme and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

I believe this is loosely similar to #793 . In this case, it seems ApiError is not properly referenced because core is not properly referenced:

core/init.py actually has ApiError in both the TYPE_CHECKING block and
all. So from auth0.management.core import ApiError should be resolvable by PyCharm. The
problem is one level up — PyCharm can't resolve auth0.management.core as a subpackage because
auth0.management.init.py doesn't reference core.

---

This happens to make the README somewhat troubling...

auth0-python/README.md

Lines 182 to 195 in e506d73

	## Exception Handling
	When the API returns a non-success status code (4xx or 5xx response), a subclass of the following error
	will be thrown.
	```python
	from auth0.management.core.api_error import ApiError
	try:
	client.actions.create(...)
	except ApiError as e:
	print(e.status_code)
	print(e.body)
	```

... in that using the following code produces what seems like an error:

Reproduction

# noinspection PyProtectedMember
from auth0.management import ManagementClient  # type: ignore[attr-defined]  # https://github.com/auth0/auth0-python/pull/785#issuecomment-4137213608
from auth0.management.core.api_error import ApiError # <---- you will see the intellisense error here

client = ManagementClient(
    domain="YOUR_TENANT.auth0.com",
    token="YOUR_TOKEN",
)

try:
    client.actions.create(...)
except ApiError as e:
    print(e.status_code)
    print(e.body)

Additional context

No response

auth0-python version

5.1.0

Python version

Python 3.13.12

[kishore7snehil]

@StephenWithPH This fix has been released as part of v5.2.0.

[jam13]

This still doesn't seem to be exported properly. auth0.management.core is not referenced.

Migrating from v4 using Auth0Error, RateLimitError and TokenValidationError, and although these still exist in the codebase, none are accessible anymore.

[StephenWithPH]

This still doesn't seem to be exported properly. auth0.management.core is not referenced.

Migrating from v4 using Auth0Error, RateLimitError and TokenValidationError, and although these still exist in the codebase, none are accessible anymore.

This may be down to interaction with Tyepshed??? See python/typeshed#14697 (comment)

[kishore7snehil]

Thanks for the follow-up, @jam13 and @StephenWithPH .I've verified that the v5 import paths work correctly at runtime and with type checkers (mypy and pyright):

  from auth0.management.core.api_error import ApiError  # works
  from auth0.management.core import ApiError  # works

@jam13 The classes you mentioned (Auth0Error, RateLimitError, TokenValidationError) are part of the authentication package in v5 and can be imported from their new location:

from auth0.authentication.exceptions import Auth0Error, RateLimitError, TokenValidationError

The v4-style path auth0.exceptions does not exist in v5. If your IDE is resolving it, that's likely coming from outdated typeshed stubs rather than the actual package , those imports will fail at runtime.

@StephenWithPH - You raise a valid point on the typeshed PR. The py.typed marker currently only covers the management subpackage, so typeshed stubs may still be providing types for the authentication side. That said, the source-level imports resolve correctly with both mypy and pyright.

Keeping this closed as the original issue is resolved in v5.

[StephenWithPH]

@kishore7snehil ... thank you for looking into this.

I think a top-level py.typed might resolve this, since it sounds like that would trigger deactivation of Typeshed stubs. See python/typeshed#14697 (comment)