Style Q: Instance variables defined outside of __init__

[Rick Johnson]

On Tuesday, March 20, 2018 at 1:43:39 AM UTC-5, Terry Reedy wrote:
[...]
> > class Card():
> >
> >      BACK_OF_CARD_IMAGE = pygame.image.load('images/backOfCard.png')
> >
> >      def __init__(self, window, name, suit, value):
> >          self.window = window
> >          self.suit = suit
> >          self.cardName = name + ' of ' + suit
> >          self.value = value
> >          fileName = 'images/' + self.cardName + '.png'
> >          self.image = pygame.image.load(fileName)
> >          self.backOfCardImage = Card.BACK_OF_CARD_IMAGE
> >
> >          self.conceal()
> >
> >      def conceal(self):
> >          self.faceUp = False
> >
> >      def reveal(self):
> >          self.faceUp = True
>
> If the single line is all these functions do, I *might*
> suggest getting rid of them.  But this is really a separate
> issue.

While i normally agree with your advice Terry, in this case,
i must protest as i am a firm believer that callers should
_never_ be fiddling with the internals of an object unless
doing so is the only available option -- and such cases of
last resort indicate a code-smell.

Whether the practice is considered Pythonic or not (i don't
care), i would strongly suggest to the OP and anyone within
ear shot, that clear interfaces must be _strictly_ utilized.

Sure, in this case a named function may be overkill,
however, even in the superfluous cases, not providing an
interface encourage callers to engage in sloppy behavior and
reinforces sloppy behavior in authors. And both parties will
be doomed to maintenance nightmares when `reveal` and/or
`conceal` grow more functional behavior.

Laziness is not always a bad thing -- i mean, let's face it
folks, python is designed to be a lazy language -- but
experience has proven that when an author refuses to provide
clear interfaces to his/her objects, the author and the
caller will both pay a heavy price in the future.

IOWs, laziness should never be allowed to wax into an
orthodoxy.