You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support # noqa comments when calling directly #181
When I tried calling flake8_trio directly from the commandline, it turns out that doesn't respect # noqa comments - which would unfortunately block direct use for now. If supporting them is viable, let's do that and add a --disable-noqa flag for the current behavior.
I'd also prefer to name the cli tool flake8-trio; underscores are pretty unusual in the terminal.
Once this is in, I think we're ready to release the big refactoring!
I'm making good progress on implementing this, but I just realized this will clash with flake-noqa. If you transition to running flake8-trio standalone, then you'll start to get NQA102 (no matching error) for all TRIOxxx codes.
I see two possible solutions:
Use a different magic word than noqa (e.g. noqa-trio)
This means you need to replace all instances of # noqa: TRIOxxx in the codebase, and possibly replace some bare # noqa as well.
If this magic word is only parsed when run standalone, then you'd need to replace back all instances when running as non-standalone. So noqa-triod errors should be suppressed when running as a plugin as well, meaning you have a somewhat confusing state where you can suppress errors in two different ways.
I can build in the equivalent flake8-noqa NQA101,102&103 support into flake8-trio. Relatively simple (I've pretty much already done it just while debugging), but will require three extra error codes. Could duplicate even more options as well, but that starts feeling silly.
you'd maybe also want an error for finding # noqa: TRIOxxx when running standalone, or also parse them when running standalone unless you give a command-line flag.
Contribute a config option to flake8-noqa where you can tell it to ignore certain codes in NQA102.
Actually yeah, after rubberducking with the comment-box - this seems like the best solution:
parse both noqa and noqa-trio comments for suppressing errors when running standalone
when run as plugin: ignore noqa markers (letting flake8 handle them so flake8-noqa works), but suppress errors marked noqa-trio.
Command-line flag to warn when finding # noqa: TRIOxxx is kind of already implemented by NQA102, but raising it when run as standalone will inform the user about the existence of noqa-trio. Although making it default-enabled means that a majority of people will disable it immediately (i.e. everybody not running flake8-nqa with NQA102), but making it default-disabled makes it kinda pointless. So maybe just make it a prominent header in the readme.
For simplicity, let's just use # noqa and say that if you use flake8-noqa but without including flake8-trio in that run it's your problem to work out what's going on. Basically option (3), since we are still compatible if you're using everything as a flake8 plugin 🙂
Activity
jakkdl commentedon Apr 28, 2023
I'm making good progress on implementing this, but I just realized this will clash with flake-noqa. If you transition to running flake8-trio standalone, then you'll start to get
NQA102(no matching error) for allTRIOxxxcodes.I see two possible solutions:
noqa(e.g.noqa-trio)# noqa: TRIOxxxin the codebase, and possibly replace some bare# noqaas well.noqa-triod errors should be suppressed when running as a plugin as well, meaning you have a somewhat confusing state where you can suppress errors in two different ways.flake8-noqaNQA101,102&103 support into flake8-trio. Relatively simple (I've pretty much already done it just while debugging), but will require three extra error codes. Could duplicate even more options as well, but that starts feeling silly.# noqa: TRIOxxxwhen running standalone, or also parse them when running standalone unless you give a command-line flag.flake8-noqawhere you can tell it to ignore certain codes inNQA102.jakkdl commentedon Apr 28, 2023
Actually yeah, after rubberducking with the comment-box - this seems like the best solution:
noqaandnoqa-triocomments for suppressing errors when running standalonenoqamarkers (letting flake8 handle them so flake8-noqa works), but suppress errors markednoqa-trio.Command-line flag to warn when finding
# noqa: TRIOxxxis kind of already implemented byNQA102, but raising it when run as standalone will inform the user about the existence ofnoqa-trio. Although making it default-enabled means that a majority of people will disable it immediately (i.e. everybody not running flake8-nqa with NQA102), but making it default-disabled makes it kinda pointless. So maybe just make it a prominent header in the readme.Zac-HD commentedon Apr 28, 2023
For simplicity, let's just use
# noqaand say that if you useflake8-noqabut without includingflake8-trioin that run it's your problem to work out what's going on. Basically option (3), since we are still compatible if you're using everything as a flake8 plugin 🙂