Remove unused local variables in Lib/ftplib.py

[ChVeen]

In order to enhance the code quality, this PR removes unused local variables (resp) in file Lib/ftplib.py.
(I guess, an issue is not needed for this small improvement.)

[picnixz]

This is a purely cosmetic change and I don't think it's necessary. There are other places where we have unused variables so I'm rather -1 on this one. I would rather prefer a PR that removes all unused variables (and thus an issue), but again, this would still be a purely cosmetic PR that I don't think maintainers would support.

[ChVeen]

Flake8 complains about more than 800 unused vars within Lib/ and more than 40 without Lib/test.
Maybe too much for a single PR...

In general, code shouldn't contain unused vars or functions.
Unused stuff bloats the code up, needs to be maintained, and some IDEs warn about this and that...

I prefer clean code, thus this PR 🤷‍♂️
But others may have a different opinion...

[picnixz]

Flake8 complains about more than 800 unused vars within Lib/ and more than 40 without Lib/test.

We don't use a linter for Lib/ as this is a matter of taste. Depending on who maintains the module, they may or may not want this (I personally use a linter but I don't update old code to make it compliant if I don't need to change something else).

In general, code shouldn't contain unused vars or functions.
Unused stuff bloats the code up, needs to be maintained, and some IDEs warn about this and that...

I doesn't really think that it needs to be maintained as it's a code that wouldn't be touched otherwise. As for IDEs warning about it, well.. it's just a simple warning. As for "bloating the code up", I'm not really convinced: it just makes the line a bit longer. What I am more worried about in general is that we have names that could be missing at runtime (we recently fixed multiple UnboundLocalErrors in email).

In general, code shouldn't contain unused vars or functions.

Unused functions may be kept due to backwards compatibility but I agree about unused vars. However, CPython's policy is that we want to avoid cosmetic PRs and prefer making such changes as part of another PR touching the code around. It's common to "clean" surrounding code when fixing bugs or adding features, though.

Maybe too much for a single PR...

Yes.

---

Now, we do cosmetic PRs if they indeed improve reading quality (e.g., replacing complex algorithms with simpler and as-efficient alternatives) but in this case, I don't think it helps more. I am even happier to see that the return value is the "response" even though it's not used. In addition, it might be used in the future, and knowing which call defines the "response" is useful. Therefore, I'm going to reject this feature, sorry!