[Python-ideas] Mitigating 'self.' Method Pollution
gokoproject at gmail.com
Sat Jul 11 22:17:28 CEST 2015
On Sat, Jul 11, 2015 at 12:18 PM, Steven D'Aprano <steve at pearwood.info>
> *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
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
> 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
> 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
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas