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

[John Wong]

Hi.

Steven D'Aprano <steve at pearwood.info> writes:

> Personally, I don't think of "self" as pollution at all. It's nice and
> explicit and helps readability.

+ 1 as well

I am definitely in the conservative camp (I don't know who else but I
am). Let's
stick to Zen of Python.

* I see no real use case why I would write self x,y instead of self.x = 1,
self.y = 2. This reminds me of Javascript var x,y.
* While this is not exactly like Javascript's "this", I can see the
resemblance, and no thanks.
* This change will be confusing to everyone reading Python code. We have to
stick to real readability, not some rare . We should not introduce this
kind of change to say "we can do X in two ways, and most people will write
in the old convention ANYWAY but be hold there is a second geeky way to do
the same thing."

Let's reserve the idea that
self x where now x is scoped to self .... reserve this idea to just
nonlocal and global - I personally haven't found a use case for nonlocal
and global in my own work but that's just my opinion.

Thanks.
John

On Fri, Jul 10, 2015 at 10:42 PM, Ryan Gonzalez <rymg19 at gmail.com> wrote:

> -1e200.
>
> I have to deal with implicit 'this' enough in C++ at the risk of writing
> "bad style" or something like that. It has bitten before. Until I started
> following C++ style guides, I always put 'this->' in front of every
> variable but still had to deal with the accidental member reference when
> you meant something else.
>
> I also like the fact that Python lets you name constructor arguments the
> same way as members, e.g.:
>
> class X:
> def __init__(self, x, y):
> self.x = x
> self.y = y
>
> You can do the same in C++, but compilers with -Wall will complain unless
> you do this:
>
> class X {
> public:
> X(int x_, int y_): x{x_}, y{y_} {}
> ...
> }
>
> which is just ugly.
>
>
> On July 10, 2015 5:31:28 PM CDT, Michael Hewitt <michael at hewitts.us>
> 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.
>>
>> Thank you for your consideration.
>>
>> Michael Hewitt
>>
>> Original Post:
>> http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html
>>
>> ------------------------------
>>
>> 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/
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> _______________________________________________
> 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/eb4306c8/attachment-0001.html>