Pylint Argument number differs from overridden method

[Wanderer]

Pylint W0221 gives the warning
Argument number differs from overridden method.

Why is this a problem? I'm overriding the method to add additional
functionality.

This
def GetRays(self, angle, pt, lmbda = 0.6):
"""
"""

angle, x, y, Rays, Power = self.ARefract(angle, pt[0], pt[1],
lmbda)
pt1 = (x, y)

return Rays, Power, angle, pt1

def ARefract(self, angle, x, y, lmbda = 0.6):
"""
"""

Nt = self.Mat.NtGet(lmbda)
self.NtSet(Nt)
angle, x, y, Rays, Power = self.Refract(angle, x, y)

return angle, x, y, Rays, Power

Over rides this

def GetRays(self, angle, pt):
"""
"""

angle, x, y, Rays, Power = self.Refract(angle, pt[0], pt[1])
pt1 = (x, y)

return Rays, Power, angle, pt1

Thanks

[Robert Kern]

On 2010-03-03 11:39 AM, Wanderer wrote:
> Pylint W0221 gives the warning
> Argument number differs from overridden method.
>
> Why is this a problem? I'm overriding the method to add additional
> functionality.

There are exceptions to every guideline. Doing this could easily be a mistake,
so it's one of the many things that Pylint checks for. Silence the warning if
you like.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Wanderer]

Thanks I was just wondering if I was overlooking something about
inheritance.

[Terry Reedy]

On 3/3/2010 12:39 PM, Wanderer wrote:
> Pylint W0221 gives the warning
> Argument number differs from overridden method.
>
> Why is this a problem?

It *could* indicate a mistake. Lint programs, by definition, are
nitpicky, and flag things that are possible problems even though
syntactically correct.

[Jean-Michel Pichavant]

This is only my opinion but you get this warning because of 2 disctinct
issues:
1/ you just made a basic mistake in your signature and need to correct it
2/ you did not make any mistake in the signature, but this warning may
reveal a (small) flaw in your class design.

I don't know the exact context for your code, but it's better to have a
consistant interface over your methods and mask the implementation
details from the user.
In your case, the getRays method may always ask for the lambda
parameters and just ignore it for one of its implementation.

And don't write empty doctrings to trick pylint. Either write them, or
remove this rule, you are loosing all the tool benefits.

JM

[Wanderer]

On Mar 4, 5:45 am, Jean-Michel Pichavant <jeanmic...@sequans.com>
wrote:

Okay different example. I'm not really using inheritance here but its
the same idea.
The wx.SpinCtrl is annoyingly integer. I want decimal values. so I
created dSpinCtrl.
It adds the argument places. It's a drop in replacement for SpinCtrl.
(okay its not, because I didn't create all the members). If you
replace SpinCtrl with dSpinCtrl the program should work the same
because the new argument places has a default value. I don't see a
problem with more arguments. Less arguments would be a problem.
Expanding functionality from a base class is what I thought
inheritance is about.

class dSpinCtrl():
"""Adds decimal values to SpinCtrl. Almost a drop in replacement
for SpinCtrl.
Adds 'places' variable for number of places after decimal point
"""

def __init__ (self,
parent,
iD = ID_SPIN,
value = wx.EmptyString,
pos = wx.DefaultPosition,
size = wx.DefaultSize,
style = wx.SP_ARROW_KEYS,
dmin = -100.0,
dmax = 100.0,
dinitial = 0.0,
places = 0):