<div><div>The hazards associated with accessing attributes that are intended as private or protected depend entirely on the situation at hand. In many cases the main issue is that the module defining the class is subject to change and there is no contract to maintain compatibility with respect to those attributes. As with all rules, avoid blind dogma, try to understand the actual consequences, and remember we are grown ups. </div><div><br/></div><div><i>We are all. Free. To do. Whatever. We want. To do</i>. - Richard Bach</div><div><br/></div><div>Regarding getters and setters, I'm convinced that these are utterly useless in Python, and often a horrendous waste of time. They are often quite necessary for future-proofing in statically typed languages such as Java, but there exists no scenario in Python in which that pattern can yield an increase in robustness, resilience, or productivity.</div><div><br/></div><div>I rarely get this passionate and one sided about an issue, but I recently witnessed a LOC increase of around 8000 lines attributable to this horrific anti-pattern, and along with it a substantial decrease in the resilience of the code base. It was horrible. I and my colleagues were unable to compose any hypothetical future scenario for which this provided any protection. In fact, ironically, there were a couple bugs caused by failure to keep the setters up to date! More code = more bugs.</div><div><br/></div><div>I find that it is usually best to just "keep it simple, stupid". If an attribute makes sense in terms of the View, and currently represented in the Model as an ordinary attribute, just make it public and don't make a big fuss over OOP ideas about hiding implementation details, (unless you can think of a "clear and present" reason for doing so). The reason you can get by with this in Python or simple, but subtle: an ordinary attribute is already syntactically equivalent to a property, so you've effectively got implementation hiding for free. Sure, you're exposing data members, but you haven't <i>committed</i> to doing so.</div><div><br/></div><div>What if the data model changes (e.g. the attribute is now stored in remote database)? If you are coming from a Java background, you can have your 30 second panic attack: Bloody Hell! We forgot to publish an accessor interface! We are so humped! Then relax. This is Python. It's all good. It's never too late. Just refactor the attribute into a @property and all is well.</div><div><br/></div><div><a href="http://docs.quantifiedcode.com/python-anti-patterns/correctness/implementing_java-style_getters_and_setters.html">http://docs.quantifiedcode.com/python-anti-patterns/correctness/implementing_java-style_getters_and_setters.html</a></div><div><br/></div><div><font style="color:#333333"><i>~ken (Sent from my phone)</i></font></div></div><div class="elided-text">On Oct 11, 2016 2:29 AM, Braun Brelin <bbrelin@gmail.com> wrote:<br type='attribution'><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello all,<div><br /></div><div>I just wanted to get the list's opinion on something. </div><div><br /></div><div>Since Python doesn't really have the concept of private and protected</div><div>attribute access protections a la Java or C++ (Yes, I know you can use</div><div>the __ and _ prefixes to declare something private or protected in</div><div>Python, but that really only does name-mangling on the attribute name</div><div>rather than explicitly disallow access to the attribute from outside the class), is it better to still access the attribute directly a la </div><div>Foo.bar = 10 or use a setter/getter approach like Foo.setBar(10)?<br /></div><div>It seems to me that option one is better, especially if I can use a descriptor with the attribute. </div><div><br /></div><div>Any thoughts?</div><div><br /></div><div>Thanks,</div><div><br /></div><div>Braun Brelin</div><div><br /></div></div>
</blockquote></div>