Should I Wrap Exceptions from External Libraries in My Python Package?

You're right; it’s a best practice to wrap the exceptions your package raises in custom ones. When you define your scoping, make sure to subclass `Exception` and document those exceptions clearly for users. It helps set their expectations. For instance, you could define a `QueryError` class for network failures and document your functions that could raise it, like so:

```python
def get_veggie_price(vegetable: str) -> float:
"""Get the price of a vegetable from the market.
:raises QueryError: if the network query fails.
"""
try:
# your fetching logic here
except urllib.error.HTTPError as e:
raise QueryError(e)
```
That way, users know what to expect!

You’ve got a few good options depending on how invested you are in your interface.

1. Just let the `urllib` exceptions bubble up and inform your users they should catch them. This keeps things simple but ties you to `urllib`, so if you switch libraries, users might break.

2. You could import `HTTPError` from `urllib` in your package and encourage users to catch `mypackage.HTTPError`. This way, you can change the underlying library later, although it does mean you need to be cautious about keeping your error interface consistent.

3. Or you can create your own custom error like `QueryError`, capturing the `urllib` error details within it. This is more work, but grants you flexibility if you change which library you use in the future.

I’d look at how the Requests library does it. They rely on `urllib3` but make sure to not expose those exceptions directly, mapping them to their own exception hierarchy. If your package is for public use, this might be worth considering to hide implementation details.

I think a good balance is to map the `urllib` exceptions to your own. For instance, you can simply add an alias for `HTTPError` in your package code:

```python
from urllib.error import HTTPError as QueryError
```
This way, users can catch `mypackage.QueryError` without being too confused about the specifics. Also, ensure you only catch exceptions when you know how to handle them!

Sometimes doing nothing is an option! You could let users handle the exceptions as they see fit. This assumes your users will have the knowledge needed to handle those errors properly.