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

Mark Lawrence breamoreboy at yahoo.co.uk
Sat Jul 11 11:03:50 CEST 2015

On 11/07/2015 08:25, Michael Hewitt wrote:
> Let's compare two versions of a method taken from some code that my 11
> year old son wrote yesterday:
> *_Current_*
>     global height
>     def keep_moving_gravity(self):
>          self.y += self.gravity
>          self.y = max(self.y, 0)
>          self.y = min(self.y, height - 1)
> *_Proposed_*
>     global height
>     def keep_moving_gravity(self):
>          self y, gravity
>          y += gravity
>          y = max(y, 0)
>          y = min(y, height - 1)
> Is anyone actually going to argue that the first version is cleaner and
> more readable than the second?

Yes, as I already have.

> As far as maintainability, the author of the first version must
> repeatedly make the same decisions over and over regarding how to scope
> each variable reference as he/she types 'y', 'gravity', and 'height'.
> The author of the second code makes these decisions exactly once at the
> top of the method and then is free to refer to each variable naturally
> without the mental overhead of prefixing each 'y' and 'gravity' with
> 'self.', but God forbid - not 'height'.  I can tell you that the mental
> overhead of this is taxing my son & is the cause of many painful
> mistakes -- just forgetting a single 'self.' prefix on one of the above
> field references can waste a significant amount of time.

Wrong, as Ben Finney has already pointed out.  You'll also have to wade 
up and down any large methods to ensure that you distinguish local 
variables from instance variables.  Frankly I see nothing in this 
proposal at all, so I'm moving from -1 to the -1000 somebody else gave 
it in the early hours of the mornig, I'm sorry but I forget who that was.

My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

More information about the Python-ideas mailing list