1

I'm overriding a method in my parent class, and I don't intend to use its only argument.

In a similar vein to this question, I want to use the underscore so my type checker (Pyright/Pylance in VSCode) doesn't give me a message:

class Parent:
    def foo(self, bar):
        raise NotImplementedError


class WithWarning(Parent):
    def foo(self, bar):  # 'bar' is not accessed
        print("Hello world")


class WithoutWarning(Parent):
    def foo(self, *_, **_):
        print("Hello world")

This seems to say "ignore any positional or keyword arguments" (I don't know whether bar gets passed positionally or with a keyword.)

But I've never seen **_ be used anywhere and my instinct tells me that if you've never seen it, you probably shouldn't be using it.

Can anyone give me evidence of some respectable Python code (standard library or similar) which uses this? If not, I'll get rid of it and just live with the error.

Update

As mentioned in the comments, to ignore positional arguments, and keyword arguments, you'd actually have to do something like:

    def foo(self, *_, *__):  # <- TWO underscores!

Now this looks really mad. Which only makes my question more pertinent: what's the accepted way of doing this?

LondonRob
  • 73,083
  • 37
  • 144
  • 201
  • 1
    Using `_` as a placeholder is considered good form, so I don't know why `**_` wouldn't be. That said, `**_kwargs` is another formulation that some linters will let you get away with. – Charles Duffy Jul 18 '22 at 12:57
  • 1
    Note that "Can anyone link me to..." is an off-site resource request, and categorically off-topic. (The "recommendation request" text in the close dialog isn't quite on-point, but the expanded text in https://stackoverflow.com/help/on-topic covers it explicitly: *Questions asking us to recommend **or find** [...] [an] **off-site resource** are off-topic[...]*) – Charles Duffy Jul 18 '22 at 12:58
  • Why not just define the foo function in the child class without including bar as a parameter at all? That shouldn't give any warning. – linger1109 Jul 18 '22 at 13:01
  • 3
    @linger1109 that would break the Liskov substitution principle, though. – jonrsharpe Jul 18 '22 at 13:04
  • What *type checker* are you using? – Daweo Jul 18 '22 at 13:10
  • 1
    I don't know why you're worried about type checkers when this gives `SyntaxError: duplicate argument '_' in function definition` – Tomerikoo Jul 18 '22 at 13:17
  • @LondonRob have you tried using a dummy statement like bar = str(bar) at the beginning of the function which would likely count as "using" the variable to the type checker? – linger1109 Jul 18 '22 at 13:27
  • @CharlesDuffy this isn't an example of the on-topic/off-topic rule you've linked to. I'm not looking for a resource, I'm looking for evidence that a particular usage is considered "respectable". And linking to an example in the stdlib is a pretty good way of proving that something is respectable, at least in some small way. – LondonRob Jul 18 '22 at 14:43
  • @Daweo I'm using pyright with Vim. – LondonRob Jul 18 '22 at 16:11
  • _nod_, but whether something is "respectable" is pretty close to asking whether it's "good practice", and that's a whole 'nother can of worms when it comes to topicality. – Charles Duffy Jul 18 '22 at 16:22
  • @CharlesDuffy yeah, that seems fair enough. I personally _love_ "is this good practice" type questions, because you usually get interesting stuff coming out about usage and readability. But I understand that it's not everyone's favourite type of question. Still, this one has already generated enough food for thought not to be closed probably. – LondonRob Jul 18 '22 at 16:24
  • 1
    There's an interesting discussion about _exactly_ this issue [over at Pyright HQ](https://github.com/microsoft/pyright/issues/1118). – LondonRob Jul 18 '22 at 16:25
  • This is also being discussed at the home of [Pyright on Vim](https://github.com/fannheyward/coc-pyright/issues/107#issuecomment-887321347). – LondonRob Jul 18 '22 at 16:30

1 Answers1

0

Not really a very well researched answer, but if you can get away without the is not accessed errors by prefixing an underscore to your variables, then that seems like the least confusing way to do it (considering the comments).

def foo(self, *_args, **_kwargs)

However if the linter still complains that _args and _kwargs are not accessed, this might be a way to get around it:

def foo(self, *args, **kwargs):
  _ = args, kwargs
rymanso
  • 869
  • 1
  • 9
  • 21
  • The `*_args` thing is a nice idea, but Pyright (or Pylance, in VSCode) still moans about this. Your idea of packing both away into `_` is maybe the best option so far! (Or maybe `*_, **__` is better??? – LondonRob Jul 18 '22 at 16:16
  • The more i think about it, the more `*_, **__` seems correct. maybe that really is the way to go about it. unfortunately its all speculation from my end too! – rymanso Jul 18 '22 at 16:23