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

Mark Lawrence breamoreboy at yahoo.co.uk
Sat Jul 11 01:49:34 CEST 2015


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



More information about the Python-ideas mailing list