Skip to content

Conversation

@Glinte
Copy link

@Glinte Glinte commented Nov 2, 2025

This is a pretty breaking change, but I made the PR just to start the discussion.

Imo it makes very little sense to not allow subclasses. I am using many third-party libraries, and basically all of them provide an exception hierarchy, for example SQLAlchemy has around 10 exception subclasses of SQLAlchemyError. Of course, it would be best if I rewrap the exceptions again, but I really want to just tell deal and the consumers of my function that it may raise any subclass of SQLAlchemyError and live on with my life, without listing out all the subclasses of SQLAlchemyError.

Tests were ran, same results on master and this branch (all 3 tests in test_mem_test.py failing)

@orsinium
Copy link
Member

orsinium commented Nov 2, 2025

the linter cannot resolve subclasses. it would be nice to migrate the linter from flake8 to mypy (like refurb does) to be able to properly resolve types but that's a giant project for which I'll never have time. so i try to keep the runtime behavior close to the current static analysis capabilities.

@Glinte
Copy link
Author

Glinte commented Nov 3, 2025

I didn't think about deal's linter, that makes sense but sucks.

I have never used flake8 before, let alone writing a plugin. Are you saying that it is impossible to use flake8 to understand type information properly, so all that is possible is an exact match without switching to mypy?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants