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

David Mertz mertz at gnosis.cx
Sat Jul 11 17:13:25 CEST 2015


The proposed version feels difficult to read, bug prone, and overwhelmingly
non-Pythonic.

The door for C++ is right down the hall.... ☺
On Jul 11, 2015 12:26 AM, "Michael Hewitt" <michael at hewitts.us> 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?  All I see when I read the first is 'self',
> 'self', 'self' -- my son's exact words to me last night.
>
> 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.
>
> As far as static analysis tools, this should honestly not be a lot of
> extra work, since the tools must already handle 'global' in a very similar
> fashion.
>
> If the 'self.' prefix really does make code clearer, then we should do
> away with the 'global' scope declaration as well as automatic local scoping
> and require prefixing of all Python variables with 'self.', 'global.' or
> 'local.'.  My mind becomes numb thinking about writing such code.  To me,
> the existence of the keyword 'global' for automatically scoping subsequent
> variable references is a strong argument that a similar 'self' scoping
> mechanism is called for as well.
>
> And, for folks who still prefer to prefix all their field references with
> 'self.', the proposal in no way prevents them from doing so.  It merely
> allows the rest of us to be a bit less wordy and more pithy in our code.
>
> Mike
>
> On Friday, July 10, 2015, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
>
>> On 10/07/2015 23:31, Michael Hewitt wrote:
>>
>>> Last night I made a post to the neopythonic blog proposing a Python 3.x
>>> feature that Guido asked me to forward to this alias.  For the full
>>> background, see the link to my post below.  For brevity, I will simply
>>> submit the proposal here.  The specific problem I am addressing is the
>>> pollution of Python methods by 'self.' to reference fields.  Here is the
>>> proposal:
>>>
>>>     The name of the first parameter to a method can be used to scope
>>>     subsequent variable references similar to the behavior of 'global'.
>>>
>>>
>>> Here are some examples:
>>>
>>>     class Foo:
>>>
>>>         def method_a(self)
>>>
>>>             self x # subsequent 'x' references are scoped to 'self'
>>>
>>>             x = 5 # same as self.x = 5
>>>
>>>         def method_b(this)
>>>
>>>             this x, y # subsequent 'x' & 'y' refs are scoped to 'this'
>>>
>>>             x = y # same as this.x = this.y
>>>
>>>         def method_c(its)
>>>
>>>             its.x = 5 # still works just like it used to
>>>
>>>
>>> This suggestion is fully backward compatible with existing Python code,
>>> but would eliminate the need to pollute future Python methods with
>>> copious 'self.' prefixes, thereby improving both readability and
>>> maintainabilty.
>>>
>>
>> I disagree completely.  When I see:-
>>
>> self.x = 1
>>
>> I currently know exactly what I'm looking at.  All I see with this
>> proposal is more work for my MKI eyeballs, which are already knackered, and
>> more work for the people who maintain our static analysis tools, as you can
>> still forget to properly scope your variables.  So -1.
>>
>>
>>> Thank you for your consideration.
>>>
>>> Michael Hewitt
>>>
>>> Original Post:
>>>
>>> http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html
>>>
>>>
>>
>>
>> --
>> My fellow Pythonistas, ask not what our language can do for you, ask
>> what you can do for our language.
>>
>> Mark Lawrence
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150711/11f76194/attachment.html>


More information about the Python-ideas mailing list