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

[John Wong]

On Sat, Jul 11, 2015 at 12:18 PM, Steven D'Aprano <steve at pearwood.info>
wrote:

>
>  *Understanding the code* is harder
> than writing it in the first place, so having to write a few extra
> selfs is a negligible cost with a big benefit. Attributes are special
> because they are state, and you have lots of state.
>
>
Actually I was taught to use "this" everywhere if I can.

But look at Michael's example code. That's real code too, it's just not
> enterprisey, and there are many Python programmers who don't write
> enterprisey code. They're beginners, or sys admins hacking together a
> short script, or editing one that already exists. For them, or at least
> for some of them, they have only a few classes with a little bit of
> state. Their methods tend to be short. Although they don't have much
> state, they refer to it over and over again.
>
> For these people, I believe, all those explicit selfs do is add visual
> noise to the code, especially if the code is the least bit mathematical
> or if there are well-known conventions that are being followed:
>

I disagree that we really need to distinguish what consituttes enterprisey
code. In fact it is a bad idea to think there is even such notion because
people should express code in the cleanest and most intuitive way possible.
Even a beginner can and should benefit from explicitness. I am sure
everyone here have read enterprisey code and know that enterprisey code is
not really enterprisey code. Complexity is a different discussion, and does
not justify why someone would want to be less explicit or more explicit.
That's same argument why can't we have make init a reserved class method,
why have __init__? I can come up with a bunch of other arguments why Python
language should do Y instead of X to make code less visually noisy. We
cannot appeal to everyone's need if the visual noise is such a no deal in
performance and in learning a language.

Sure people can write "self" like this:

def regular_function(elf, self):
    # self is just some Python object...
    elf.name = 'foo'
    self.name = 'bar'

But this is still clear to beginner that hey this is just a regular
function, self in this case is some kind of object....

Anyway, when I was a student, scoping was a very popular question among my
peers when they first learn a new language.

On Sat, Jul 11, 2015 at 12:04 PM, Michael Hewitt <michael at hewitts.us> wrote:

> I am officially dropping my original proposal in favor of Nick's.  Using a
> single '.' prefix to reference class variables is brilliant.  It has the
> added benefit of scoping auto-completion within IDEs, which is incredibly
> helpful for beginners and veterans alike.


I still -1 on the dot prefix. We might as well adopt $ in that case. "dot"
is a poor choice. It is one of the most easily missed character to type.
And again I don't see the benefit of having self. and $ co-exist. We should
choose one way, but obviously this cannot be the case because we need
backward compatibility.


On Sat, Jul 11, 2015 at 3:41 PM, David Mertz <mertz at gnosis.cx> wrote:

> On Sat, Jul 11, 2015 at 12:10 PM, Nikolaus Rath <Nikolaus at rath.org> wrote:
>
>> > class Vector:
>> >     def abs(self):
>> >         return sqrt(x**2 + y**2 + z**2)
>> >         # versus
>> >         return sqrt(self.x**2 + self.y**2 + self.z**2)
>> >
>> >
>> > I expect that most people, with any
>> > knowledge of vectors, would have understood that the x, y, z in the
>> > first return must refer to coordinates of the vector.
>
>
>
>> Thanks for that excellent post. I hope it'll cause some people to
>> reconsider. Although there seems to be a flood of objection mails, most
>> of them seem more instintive than rational to me.
>>
>
> This is a great example of why the proposal is a bad one.  Yes, not using
> magic makes a one-line function slightly longer (and even slightly less
> readable).
>
> But I also don't want to have to guess about WHICH 'x' or 'y' or 'z' is
> the one being used in calculation of Cartesian distance.  Sure, an obvious
> implementation of a Vector class probably has x, y, z attributes of self.
> The example was rigged to make that seem obvious.  But even then, I don't
> really know.  Maybe the z direction of the vector is stored as a class
> attribute.  Maybe the class expects to find a global definition of the z
> direction.
>
> Sure, keeping the z direction somewhere other than in self is probably
> foolish if you assume "Vector" means "generic vector".  What if the class
> was called "RestrictedVector"? Would you know without reading the full
> class and docstring exactly in what respect it is "restricted"?  E.g. are
> you sure it's not "restricted in the z dimension"?
>
> As someone else points out, if you WANT local variables in a method, you
> are welcome to use them.  E.g.:
>
>     def times_matrix(self, matrix):
>         x, y, z = self.x, self.y, self.z
>         # Many more than one line of implementation
>         # ... stuff with matrix indexing and referencing x
>         # etc.
>         return result_matrix
>
> No one stops you now from giving local names to values stored in the
> instance within a method body.  But when you do so, you KNOW 30 lines later
> that they are local names, even after the "local-looking name is actually
> an attribute" declaration has scrolled away.
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>
> _______________________________________________
> 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/ef21dcf0/attachment-0001.html>