<div dir="ltr"><div class="gmail_quote">On Sat, Jul 11, 2015 at 12:18 PM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> *Understanding the code* is harder<br>
than writing it in the first place, so having to write a few extra<br>
selfs is a negligible cost with a big benefit. Attributes are special<br>
because they are state, and you have lots of state.<br>
<br></blockquote><div><br></div><div>Actually I was taught to use "this" everywhere if I can.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But look at Michael's example code. That's real code too, it's just not<br>
enterprisey, and there are many Python programmers who don't write<br>
enterprisey code. They're beginners, or sys admins hacking together a<br>
short script, or editing one that already exists. For them, or at least<br>
for some of them, they have only a few classes with a little bit of<br>
state. Their methods tend to be short. Although they don't have much<br>
state, they refer to it over and over again.<br>
<br>
For these people, I believe, all those explicit selfs do is add visual<br>
noise to the code, especially if the code is the least bit mathematical<br>
or if there are well-known conventions that are being followed:<br></blockquote><div><br></div><div>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. <br></div><div><br></div><div>Sure people can write "self" like this:<br><br></div><div>def regular_function(elf, self):<br></div><div> # self is just some Python object...<br></div><div> <a href="http://elf.name">elf.name</a> = 'foo'<br></div><div> <a href="http://self.name">self.name</a> = 'bar'<br></div><br></div><div class="gmail_quote">But this is still clear to beginner that hey this is just a regular function, self in this case is some kind of object....<br></div><div class="gmail_quote"><br></div>Anyway, when I was a student, scoping was a very popular question among my peers when they first learn a new language.<br><br>On Sat, Jul 11, 2015 at 12:04 PM, Michael Hewitt <span dir="ltr"><<a href="mailto:michael@hewitts.us" target="_blank">michael@hewitts.us</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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.</blockquote><div><br></div>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.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 11, 2015 at 3:41 PM, David Mertz <span dir="ltr"><<a href="mailto:mertz@gnosis.cx" target="_blank">mertz@gnosis.cx</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Sat, Jul 11, 2015 at 12:10 PM, Nikolaus Rath <span dir="ltr"><<a href="mailto:Nikolaus@rath.org" target="_blank">Nikolaus@rath.org</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><span class="">> class Vector:<br>
> def abs(self):<br>
> return sqrt(x**2 + y**2 + z**2)<br>
> # versus<br>
> return sqrt(self.x**2 + self.y**2 + self.z**2)<br>
><br>
><br></span><span class="">
> I expect that most people, with any<br>
> knowledge of vectors, would have understood that the x, y, z in the<br>
> first return must refer to coordinates of the vector. </span></span></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for that excellent post. I hope it'll cause some people to<span class=""><br>
reconsider. Although there seems to be a flood of objection mails, most<br>
of them seem more instintive than rational to me.<br></span></blockquote><div><br></div><div>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). </div><div><br></div><div>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.</div><div><br></div><div>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"?</div><div><br></div><div>As someone else points out, if you WANT local variables in a method, you are welcome to use them. E.g.:</div><div><br></div><div> def times_matrix(self, matrix):</div><div> x, y, z = self.x, self.y, self.z</div><div> # Many more than one line of implementation</div><div> # ... stuff with matrix indexing and referencing x</div><div> # etc.</div><div> return result_matrix</div></div><br clear="all"><div>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.</div><span class=""><div><br></div>-- <br><div>Keeping medicines from the bloodstreams of the sick; food <br>from the bellies of the hungry; books from the hands of the <br>uneducated; technology from the underdeveloped; and putting <br>advocates of freedom in prisons. Intellectual property is<br>to the 21st century what the slave trade was to the 16th.<br></div>
</span></div></div>
<br>_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br></blockquote></div><br></div>