On Tue, May 3, 2016 at 4:25 PM, Michael Orlitzky <mich...@orlitzky.com> wrote: > On 05/03/2016 09:22 AM, Erik Bray wrote: >> >> You seem to have this view that the sole purpose of getter and setter >> methods is to update a private member of some object. Am I >> understanding that correctly? Because either I'm misunderstanding >> you, or you seem to be confused about why property was created for >> Python. >> > > That's not my view on getter/setter methods. Those are useful for doing > all sorts of things: type checking, validation, making variable > access/assignment override-able in subclasses, etc.
Okay, right, just making sure.... > I'm questioning whether or not the syntactic sugar AROUND getter/setter > methods is useful. In languages with true private member variables, you > have to write boilerplate getter/setter methods all the time. There, the > trade-off is beneficial. Having some additional language syntax to > eliminate the boilerplate is worth it, even if all of your > getters/setters are trivial (which they should be). I don't think it's just "syntactic sugar". If anything it's setter and *especially* getter methods that are backwards, but unfortunately necessary in languages like Java that don't have a natural way to interpose in attribute access. *Because* of this it's necessary in Java to explicitly write and use mutator methods for everything, even though the vast majority that ever get written don't do much beyond read or update a private member variable. It's the mutator methods that are the conceptual overhead (for consumers of the API). I call it premature encapsulation. > But in python? There's no need to wrap member variables in getter/setter > methods: you can always access them. If you want to do something > nontrivial -- like ensure that you're setting some value to an integer > -- then sure, a setter method is appropriate. But now you have a setter > method that can throw a TypeError. What do we gain by making that a > @property? It changes, > > c.set_x(3) > > to > > c.x = 3 > > which hides the fact that you're calling a method. Is it worth it? In > the "cons" column, we have > > * the new @property syntax The property class actually predated the @decorator syntax by quite a bit. The @decorator syntax has countless uses, and in the case of properties helps make the code more explicit. > * the mental overhead of having a new concept As opposed to the mental overhead of unnecessary encapsulation? > * the need for end-user documentation Huh? > * the need for a policy regarding when (not) to use @property > * the possibility of bugs like the one that started this thread You're taking the position that anything that *might* (one day, maybe, or presently) have any side effect other than returning or setting a member variable must be *syntactically* used as a method. The Pythonic approach has different semantics. An attribute is some characteristic of an object "name", "color". A method is something that object does "run", "compute". This is completely independent of implementation details. Of course if you want to add validation to a setter you implement that in a method, but the API is still just obj.name = 'Foo', because that's how you update an attribute. Understanding that attribute access *may* have side-effects requires no more conceptual overhead or documentation than the fact that methods may have side-effects. Do you wrap every method call with a try/except? No. Likewise you wouldn't with attribute access unless the documentation tells you you might have to. (One thing I do miss from Java is the "raises" syntax.) As you said, in Python there are no private members so there's no need to wrap them in setters and getters, and so we don't by default--all attributes are public, which is often more natural. If an attribute is safe being public knowledge then it darn well should be. If later we need to add mutator methods we can do that, but in a quiet way that doesn't change the existing syntax for accessing that attribute. And if we add an explicit setter method, in addition to allowing the undecorated attribute assignment that people were already using, then you're really getting into trouble. Anyways we can agree to disagree on this, and even within the Python community you'll find different opinions, especially regarding things like how much calculation should be done in the getter of a property, or what kinds of exceptions should be raised. But by and large you'll find that the use of @property is considered "Pythonic", and explicit mutator methods markedly less-so in *most* cases. I feel that Sage is already badly divorced from the rest of the Python community as it is. Erik -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
