<br><br><div class="gmail_quote">On Sat, Jan 31, 2009 at 9:08 AM,  <span dir="ltr"><thmpsn.m.k@gmail.com></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Jan 30, 12:15 am, Chris Rebert <<a href="mailto:c...@rebertia.com">c...@rebertia.com</a>> wrote:<br>
> - Python supports encapsulation. Prefixing an attribute/method with an<br>
> underscore indicates that other programmers should treat it as<br>
> 'private'. However, unlike B&D languages, Python itself does nothing<br>
> to enforce this privacy, leaving it instead to the good judgement of<br>
> the programmer, under the philosophy that "We're all consenting adults<br>
> here".<br>
<br>
</div>How do you know? (I know I'm not.)<br>
<br>
Seriously, though, the lack of private members does allow for ugly<br>
hacks in user code, and you know there are always ugly hackers.<br>
<div class="Ih2E3d"></div></blockquote><div><br>So what, though?<br><br>If you're a application developer, writing your own code: just don't do it.<br>You've now achieved enforced encapsulation! Why does the language<br>need to check that?<br><br>If you're the user of a library and you need access to a private member<br>of that library: again, just don't do it! Write a patch and maintain a<br>private fork to expose the member function, and submit it to the developer<br>and hope it gets included so you don't have to maintain the private fork.<br><br>For those people who need access to that internal Right Now and don't<br>want to wait for the developer to expose it, because its important to them<br>why should the language forbid it? Sure, its an ugly hack. But so what? <br>They're doing it, at the risk of future breakage if anything changes in<br>that undocumented internal detail, because they need to. There are<br>situations where maintaining a private fork to expose something in a<br>library is a far greater burden and not worth it.<br><br>If you're the writer of a library, why do you even care if the people who<br>use it access an undocumented internal? If anything breaks its not<br>your problem.<br><br>If you're in some corporate environment which has a 'no fiddling with<br>the privates of another teams modules' -- why do you need the language<br>to enforce that restriction? If your employees aren't following the coding<br>standards of your own organization, that's a problem. Surely it'd come up<br>very quickly with even the most cursory of reviews, after all "obj._variable"<br>is really obviously not "self._variable" and so pretty obviously accessing<br>someone elses private state.<br><br>If you're in an open source environment and are worried about quality<br>of code from lots of contributors who aren't being paid: again, reviews<br>should be happening /anyways/.<br><br>In the end, why bother? If you believe in absolute encapsulation its<br>extremely easy for you to get it in Python, today... don't touch someone<br>elses privates. <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
> This allows people to meddle with internals, at their own risk,<br>
> if it ends up being absolutely necessary.<br>
<br>
</div>If it ends up being necessary, the class's design is flawed. (Though<br>
in this case, the flaw is easily solved by simply providing a getter.)</blockquote><div><br>Sure, the design is flawed. Doesn't change the fact that you need to access<br>that internal state. "Providing a getter" is not necessarily simple: what if<br>its someone elses code? At the very least you have to maintain a private<br>fork then /or/ wait until they get around to fixing the design. Sometimes that's <br>no big deal. Sometimes it is. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In the absence of private/protected, Python should at least provide<br>
something similar to C++'s 'const' or Java's 'final'. (Similar, not<br>
equivalent, because then the object itself wouldn't be able to<br>
manipulate its own members!)</blockquote><div><br>I find marking my constants as SOME_CONSTANT instead of some_constant<br>to be more then sufficient usually. In the case where I do want to let someone<br>read a piece of data and not write it, I find a getter accessing a private member<br>variable without a corresponding setter perfectly fine.<br><br>If the users of the code choose to dig inside my class and fiddle with that<br>private member -- woe on them! I wash my hands of any trouble they<br>have.<br><br>--Stephen <br></div></div><br>