[Python-ideas] Mitigating 'self.' Method Pollution

Stephen J. Turnbull stephen at xemacs.org
Mon Jul 13 04:49:15 CEST 2015

Chris Angelico writes:

 > Alternate proposal:
 > # You could in-line this if you want to.
 > def limit(low, n, high):
 >     """Limit a number to be within certain bounds"""
 >     return min(low, max(n, high))
 > def keep_moving_gravity(self):
 >     self.y = limit(0, self.y + self.gravity, height - 1)
 > There are precisely two references to self.y (one reading, one
 > writing), and one reference to self.gravity.

That was my first reaction.

 > Bad code is not itself an argument for a language change. Sometimes
 > there's an even better alternative :)

If you're a language wonk, it's obviously better, true (well, I'm a
wannabe wonk so I say that and cross my fingers for luck :-).

But if you're a very new and possibly very young programmer (both
meaning you have little experience abstracting in this way) who's
basically scripting your way through the problem, defining an
"internal" function to be used once looks like throwing the garbage in
the garage through a window onto the lawn.

I think this is going to be be one of those features that "scripters"[1]
and "programmers" evaluate very differently.

Personally, I'm -1 but that says more about my proclivities than about
the proposal. :-)


[1]  Sorry if that sounds pejorative.  It's not intended to.  I tried
to find a better term but failed.

More information about the Python-ideas mailing list