On Monday, May 2, 2016, Michael Orlitzky <mich...@orlitzky.com> wrote:
> On 05/02/2016 06:07 AM, Erik Bray wrote: > > On Mon, May 2, 2016 at 10:35 AM, Jeroen Demeyer <jdeme...@cage.ugent.be > <javascript:;>> wrote: > >> My vote: > >> > >>> [X] Phase out properties which perform any non-trivial computation > >> > >> > >> In certain cases, properties might be useful (but it could very well be > that > >> there are 0 such cases in Sage). > > > > I generally feel that properties *should* be used in general for > > invariants of some object, regardless of how it's computed in the > > first place. I see the point about not using them for "non-trivial" > > computations but I also find the lack of a clear definition of > > "non-trivial" troubling. > > > > Properties, in any programming language, are syntactic sugar over > getter/setter methods on private member variables. In a language like > C#, they're useful and you have a sensible rule for when to use them: > use properties to get/set private member variables, and methods for > everything else. So basically, properties do no computation at all. Another hugely relevant factor for us is that sage is used mostly interactively and with extensive use of doc strings and introspections. Most Python code and libraries (and most C# code) are normally used from other Python code/libraries, not interactively. Sage is somewhat unusual in this regard. > > In python, all member variables are public, so the concept of a property > is a bit redundant. It's hard to come up with a "when to use properties" > rule in python, because the only rule that makes sense doesn't apply. > Anywhere you could use a property, you can use a "public" member > variable instead (if you can't, then you wanted a method to begin with). > > The one useful feature of @property is that it lets you document your > member variables. If I have a class with a "public" nrows member > variable, then I can't document it so that when a user runs foo.nrows?, > it tells him what that variable is supposed to do. By creating a > property (which is only syntactic sugar over a getter method), I gain > the ability to add a docstring on what would otherwise be a variable. > > So, the rule I would put forth is: use @property to document public > member variables, and methods for anything else. > > -- > 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 <javascript:;>. > To post to this group, send email to sage-devel@googlegroups.com > <javascript:;>. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- Sent from my massive iPhone 6 plus. -- 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.
