Why is perror() a static method?

[kotfu]

All of the other output methods (pfeedback(), pwarning()), are regular methods on cmd.Cmd2. Why is perror() a static method?

[kmvanbrunt]

It doesn't use self

[kotfu]

Great for our pylint checking. But it prevents someone from overriding it and using self (say to look at self.debug). How should we balance our benefit with the benefit for consumers of our API?

[kmvanbrunt]

I didn't consider that case. When the self.debug logic was moved to pexcept(), perror() just became a convenient way to send text to sys.stderr and color the text. If you think developers would want to access self in overrided versions of perror, we can add it back.

[kotfu]

I honestly don't know how common this use case would be. I stumbled upon it because in one of my cmd2 based apps, I overrode perror() and made it smart enough to do stack traces if debug was set.

I really could go either way. On one hand, perror() doesn't use self, so I should be a static method. On the other hand, none of the other output convenience methods are static, so to be consistent, perror() shouldn't be either.

[kmvanbrunt]

I'm OK changing it back since it's a public method that people may want to override.

[kmvanbrunt]

I tested the current code and found it's possible to override perror() with a version that takes self. Do you still want it changed for consistency in signatures?