Revive PEP 640 - Unused variable syntax

[Nineteendo (Nice Zombies)]

It’s just a little annoying if I have already given the answer to a question:

@alicederyn

What has changed since this was last suggested?

@Nineteendo

The old proposal didn’t allow for named throwaway arguments.

@mikeshardmind

anything having changed since that was rejected

---

@Nineteendo

If we allow to specify a name, it could also be used to maintain LSP, as a leading _ doesn’t work.

@mikeshardmind

I don’t see a usecase here

---

@Nineteendo

Real world example that would benefit from this

@mikeshardmind

If you’re saying that this would be a typehint to mark that a variable isn’t ever used, then just disable the specific warning whatever linter is giving you for an unused variable.

[alicederyn (Alice)]

This isn’t “repeating an argument”, it’s telling you your communication is confusing and hard to be confident about. I don’t think it’s appropriate to respond to that by telling off the person who didn’t understand what you were trying to say. I also think complaining that people who engage with you in good faith are “annoying” you is very likely to put people off from interacting with you at all.

Now, I know I’m restating previous comments here, but given the previous PEP was rejected for lack of support, I would have expected you to welcome information about what support you are likely to get on this, so here goes:

pylint’s refactoring warnings are deliberately noisy, by design. It would be wagging the dog to take the existing solution for suppressing them and make bespoke language syntax for each one to suppress those warnings. I don’t see a compelling argument here that the code you linked would be any clearer for this: instead of an easy-to-Google warning code, you now have an obscure ? that cannot be easily discovered.

I don’t see a potentially tiny performance improvement as justifying a whole new syntax change either; if nothing else, you would need to demonstrate a clear win over just adding unused assignment analysis to the upcoming JIT, I think.

I believe your new example is more easily solved by using the new @override decorator and having Ruff disable its noisy PLR warning when it sees it.

[Nineteendo (Nice Zombies)]

@alicederyn

your communication is confusing and hard to be confident about

OK, it indeed looks like it wasn’t very clear in this case I didn’t make the link a one-box, as it wasn’t very important for my argument, my bad.

@alicederyn

I don’t think it’s appropriate to respond to that by telling off the person who didn’t understand what you were trying to say.

In that case you can just ask for clarification, then I at least know you read my response.

@alicederyn

I don’t see a compelling argument here that the code you linked would be any clearer for this

It’s not about clarity: in the past I didn’t use a type checker leading to unmaintainable code. Now I have 5 linters enabled at the strictest settings. Any type comment I have to add feels like a failure of the language.

[Nineteendo (Nice Zombies)]

That’s all I wanted to say, really. My addition isn’t sufficient to convince anyone.
Thanks for the feedback, I hope I’ll one day suggest something you like.

[Rosuav (Chris Angelico)]

@Nineteendo

I hope I’ll one day suggest something you like.

I hope you’ve used this experience to learn more about how suggestions work and how to put something forward.