async102 not applicable to asyncio

[RomanValov]

Whilst #257 is not implemented do not trigger ASYNC102 for asyncio

[Zac-HD]

Thanks, @RomanValov - this looks great!

If @jakkdl wants to confirm that'd be great; otherwise I'll merge in a few days 🚀

[RomanValov]

I'm not really sure sprinkling "ASYNCIO_NO_ERROR" across eval files is a way to go, in particular:

1. asyncio102.py, asyncio102_trio.py and asyncio102_anyio.py already had NOASYNCIO directive. Nevertheless, tests complains with a suggestion to add "[library]NOERROR" directive, i.e.:

FAILED tests/test_flake8_async.py::test_eval[ASYNC102-asyncio-noautofix-normal] - AssertionError: eval file giving no errors w/ only_check_not_crash, consider adding [library]NOERROR
FAILED tests/test_flake8_async.py::test_eval[ASYNC102-asyncio-autofix-normal] - AssertionError: eval file giving no errors w/ only_check_not_crash, consider adding [library]NOERROR

2. it may be desired to chose another example for noqa_no_autofix.py since ASYNC102 is no longer universal.

Any other comments would be welcome

[jakkdl]

I'm not really sure sprinkling "ASYNCIO_NO_ERROR" across eval files is a way to go, in particular:

1. asyncio102.py, asyncio102_trio.py and asyncio102_anyio.py already had NOASYNCIO directive. Nevertheless, tests complains with a suggestion to add "[library]NOERROR" directive, i.e.:

FAILED tests/test_flake8_async.py::test_eval[ASYNC102-asyncio-noautofix-normal] - AssertionError: eval file giving no errors w/ only_check_not_crash, consider adding [library]NOERROR
FAILED tests/test_flake8_async.py::test_eval[ASYNC102-asyncio-autofix-normal] - AssertionError: eval file giving no errors w/ only_check_not_crash, consider adding [library]NOERROR

No this is perfect. NOASYNCIO is a marker that should be avoided since it effectively means "ignore this file with this library" and it was only there due to the known limitations with the check. ASYNCIO_NO_ERROR is perfect as it indeed means "this file should not raise any errors with this library". See https://flake8-async.readthedocs.io/en/latest/contributing.html#anyio-no-error-trio-no-error-asyncio-no-error for documentation on the magic markers.

2. it may be desired to chose another example for noqa_no_autofix.py since ASYNC102 is no longer universal.

Ye this would ideally be fixed. I can do it in a followup if you're not comfortable, but you can copy tests from pretty much any other universal rule that does not have autofix. ASYNC109 looks like a good and simple candidate without any library-specific logic.

[jakkdl]

ASYNC120 has the same issue as ASYNC102 wrt asyncio, so if you don't mind you can expand the scope of this PR to also cover async120 with a small logic change here.

[RomanValov]

as per my understanding async120 is still relevant to asyncio.
in case of async102 -- if cancellation occured in try block, it remains in except/finally blocks with trio/anyio
in case of async120 -- it only checks cancellation occurs during except ... block which is still valid for asyncio
please correct me if I'm missing something

[jakkdl]

sorry no, you're totally right. Ignore me

[RomanValov]

I'm not really sure sprinkling "ASYNCIO_NO_ERROR" across eval files is a way to go, in particular:

1. asyncio102.py, asyncio102_trio.py and asyncio102_anyio.py already had NOASYNCIO directive. Nevertheless, tests complains with a suggestion to add "[library]NOERROR" directive, i.e.:

FAILED tests/test_flake8_async.py::test_eval[ASYNC102-asyncio-noautofix-normal] - AssertionError: eval file giving no errors w/ only_check_not_crash, consider adding [library]NOERROR
FAILED tests/test_flake8_async.py::test_eval[ASYNC102-asyncio-autofix-normal] - AssertionError: eval file giving no errors w/ only_check_not_crash, consider adding [library]NOERROR

No this is perfect. NOASYNCIO is a marker that should be avoided since it effectively means "ignore this file with this library" and it was only there due to the known limitations with the check. ASYNCIO_NO_ERROR is perfect as it indeed means "this file should not raise any errors with this library". See https://flake8-async.readthedocs.io/en/latest/contributing.html#anyio-no-error-trio-no-error-asyncio-no-error for documentation on the magic markers.

Hm. I'm pretty okay with ASYNCIO_NO_ERROR directive here. It just looks counter-intuitive that test file raises an error with asyncio if it has NO_ASYNCIO directive.

2. it may be desired to chose another example for noqa_no_autofix.py since ASYNC102 is no longer universal.

Ye this would ideally be fixed. I can do it in a followup if you're not comfortable, but you can copy tests from pretty much any other universal rule that does not have autofix. ASYNC109 looks like a good and simple candidate without any library-specific logic.

Done

[jakkdl]

Everything looks perfect now, thanks for the PR!

No this is perfect. NOASYNCIO is a marker that should be avoided since it effectively means "ignore this file with this library" and it was only there due to the known limitations with the check. ASYNCIO_NO_ERROR is perfect as it indeed means "this file should not raise any errors with this library". See https://flake8-async.readthedocs.io/en/latest/contributing.html#anyio-no-error-trio-no-error-asyncio-no-error for documentation on the magic markers.

Hm. I'm pretty okay with ASYNCIO_NO_ERROR directive here. It just looks counter-intuitive that test file raises an error with asyncio if it has NO_ASYNCIO directive.

I suppose the marker is somewhat confusingly named. Should maybe be something like SKIP_ASYNCIO (though the file is still eval'd, it just skips validating whether the errors are correct) or IGNORE_ASYNCIO / IGNORE_ASYNCIO_ERRORS.

[trio-bot]

Hey @RomanValov, it looks like that was the first time we merged one of your PRs! Thanks so much! 🎉 🎂

If you want to keep contributing, we'd love to have you. So, I just sent you an invitation to join the python-trio organization on Github! If you accept, then here's what will happen:

• Github will automatically subscribe you to notifications on all our repositories. (But you can unsubscribe again if you don't want the spam.)

• You'll be able to help us manage issues (add labels, close them, etc.)

• You'll be able to review and merge other people's pull requests

• You'll get a [member] badge next to your name when participating in the Trio repos, and you'll have the option of adding your name to our member's page and putting our icon on your Github profile (details)

If you want to read more, here's the relevant section in our contributing guide.

Alternatively, you're free to decline or ignore the invitation. You'll still be able to contribute as much or as little as you like, and I won't hassle you about joining again. But if you ever change your mind, just let us know and we'll send another invitation. We'd love to have you, but more importantly we want you to do whatever's best for you.

If you have any questions, well... I am just a humble Python script, so I probably can't help. But please do post a comment here, or in our chat, or on our forum, whatever's easiest, and someone will help you out!