Remove the walrus operator for Python 3.6 compatibility

[nforro]

Related to #444.

We still support EL8 and thus Python 3.6. CI didn't catch this because it didn't even run on RHEL8 (dcermak can't run tests (and builds) internally - is there a way for a repo owner to overcome this?).

[softwarefactory-project-zuul]

Build succeeded.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/3d365d3d8f5d42a59abf868cda11aa38

✔️ pre-commit SUCCESS in 1m 48s
✔️ specfile-tests-rpm-deps SUCCESS in 1m 03s
✔️ specfile-tests-pip-deps SUCCESS in 1m 02s

[lbarcziova]

dcermak can't run tests (and builds) internally - is there a way for a repo owner to overcome this?

I would say just by manual comment triggering

[majamassarini]

it is just a test, so it is fine as it is.
But I am wondering why don't move the variables declarations at the beginning of the test, in an old style way, and use them later (instead of repeating the strings?)

[nforro]

I would say just by manual comment triggering

Right, I actually did that on #445 but the test jobs kept erroring so I didn't even try on the other PR. But the incompatibility would have been caught already during build, so I should have done it anyway.

[nforro]

But I am wondering why don't move the variables declarations at the beginning of the test, in an old style way, and use them later (instead of repeating the strings?)

You mean outside of test functions? I think that would make the readability worse.

[softwarefactory-project-zuul]

Build succeeded (gate pipeline).
https://softwarefactory-project.io/zuul/t/packit-service/buildset/55dea3558272471eba2ac497e0c51901

✔️ pre-commit SUCCESS in 1m 47s

[lbarcziova]

Right, I actually did that on #445 but the test jobs kept erroring so I didn't even try on the other PR. But the incompatibility would have been caught already during build, so I should have done it anyway.

we could also add the checks at least for builds to the required ones for merging