Update pyflakes to version 2.2.0

[Numerlor]

The new version introduces support for assignment expressions (changelog).
Currently when lint is ran with the expression in the code, pyflakes will crash flake8.
Updating the version fixes this but a noqa ignore is still necessary because pycodestyle did not yet receive an update and does not recognize the new syntax with a colon.

The update will introduce these lint errors: https://paste.fuelrats.com/rotukasohe.txt
where F999s are f-strings with no expressions inside of them and the F821s referring to this method definition's literals in the calls inside the typehints

bot/bot/cogs/moderation/management.py

Lines 49 to 56 in b44caed

	async def infraction_edit(
	self,
	ctx: Context,
	infraction_id: t.Union[int, allowed_strings("l", "last", "recent")],
	duration: t.Union[Expiry, allowed_strings("p", "permanent"), None],
	*,
	reason: str = None
	) -> None:

[kwzrd]

How do we feel about F999? I recall a discussion in #dev-contrib regarding multi-line strings such as:

string = (
    f"First line with some {param} "
    f"second line without params"
)

If I remember correctly, the majority of our core devs are in favour of keeping the second f as it aligns the literals.

EDIT: I also believe some of us feel strongly against using the walrus what-so-ever.

[Numerlor]

Looks like the joined f-strings are taken care of, taking your snippet we only get an error about param

D:\pycon>pyflakes splitfstrings.py
splitfstrings.py:2:29 undefined name 'param'

I don't know about the walrus but it can be nice to use in some simple cases without sacrificing any readability.
The pyflakes update still brings useful things so if the walrus is decided against; a notice could be posted or the flake8-walrus package can be used which forbids them.

[kwzrd]

Looks like the joined f-strings are taken care of ...

That's good to hear, thanks for the clarification.

For the record, I'm not opposed to this. I'm just hoping to get a discussion started to see whether we're all collectively on board.

I like the walrus myself, and I recently bumped pyflakes to 2.2.0 in one of my projects. It is, however, disappointing that even then, the lines still need to be noqa to avoid the problems you mentioned.

[kwzrd]

Sorry, I did not properly read yesterday and didn't realize pyflakes has had a release. I thought we'd still have to grab the specific commit the adds assignment expression support. Let's do this then, I don't see a reason to wait, and apologies again.

[kwzrd]

Good news is that pycodestyle already supports walrus on master and is only waiting on a proper release: PyCQA/pycodestyle#911.

[Numerlor]

Ah, looks like flake8 is incompatible with the newest pyflakes and the above missing placeholder error codes are wrong because of that, the only thing incompatible changes are the error codes which were fixed in this merge commit thatfixes it by simply updating a dict PyCQA/flake8@6efb15c

Do we care about the error codes enough to delay this until a release? Couldn't find any hints on when that may be.

[kwzrd]

Hmm, I'd probably lean towards just waiting on a proper flake8 release then.

[sco1]

Let's just wait for the flake8 3.8.0 release. The alpha is out and it doesn't make sense to add a bunch of manual dependency pins just to chase the walrus.

[sco1]

flake8 3.8 is now released: https://pypi.org/project/flake8/3.8.0/

[lemonsaurus]

flake8 version will be bumped to 3.8 in #947