Thanks for all the comments.  I will probably just go with the approach of 
calling the reset method from my __init__.

I guess what I didn't show (in order to keep the example simple) is that I 
typically have a number of start-up parameters that are passed into the 
__init__method that are set once, then I initialize some number of instance 
variables (attributes :)  ).  Therefore, I typically would do the "one time" 
initialization first, then call the reset method for values that would be set 
and reset each time the game is played.  

Thanks,

Irv


> On May 29, 2019, at 2:58 AM, e1000 <e1...@globenet.org> wrote:
> 
> hello,
> 
> having been a long term Pylint-maintainer, I'd advocate a more flexible 
> approach:
> 
> On 25/05/2019 20:29, Irv Kalb wrote:
>> The obvious solution is to have the __init__ method call the reset method:
>> class Game:
>>     def __init__(self):
>>          self.reset()
>>     def reset(self):
>>           self.score = 0
> 
> I think this is the right solution, specially if the reset code is just 
> following the __init__ code. and this is what I do generally...
>> That does work fine and I like it.  But it breaks a general rule that you 
>> should declare all instance variables in the __init__ method.  I use PyCharm 
>> for the development of these games, and the "linter" (over the right side 
>> scroll bar) always flags this as a warning that a variable like this is not 
>> defined in my __init__ method.
>> I'm looking for a general solution that solves this.
> 
> My general point of view is that it is more important to avoid the 
> nonsensical line like
> 
> >         self.score = None # ...
> 
> than to obey exactly PyCharm or any other linter. In Pylint, there is (or 
> was?) a system to avoid warning messages, which in my opinion fits very well 
> to that kind situation. As once stated a former coworker, fitting too closely 
> to the rules will generate bad code.
> 

Reply via email to