On Wed, May 28, 2014 at 12:59 PM, Volker Braun <vbraun.n...@gmail.com> wrote: > On Wednesday, May 28, 2014 5:35:18 PM UTC+1, Nils Bruin wrote: >>> >>> Non-underscore attributes implement a mutable interface. >> >> I wasn't aware of that convention. Is it documented somewhere, with >> rationale? > > > Python provides @property and @foo.setter to make this convention work > safely, so clearly its a common pattern.
For the record, I wrote a ton of code in 2004-2006 that followed the pattern Volker describes exactly, following standard Python convention back then. At the time there were no decorators or properties in Python. So using underscore to keep things private was the only option. >> >> - An accessor method allows a docstring to be attached, so it provides a >> documentation hook. This is something we could find a solution to. > > > Docstrings can be attached to any attribute, no? When properties were added to Python, and Sage got them, I was not convinced and didn't want to switch all the code to them. Why? Because Sage (unlike most Python code) is usually used interactively, and I've spent a lot of time watching people use Sage. People can easily learn the following Ipython-invented way of working: sage: f = Foo() sage: f.[tab] sage: f.something? docstring about how to call something sage: f.something(...) With properties, guess what happens? Suppose f.something is a property that's an immutable number, e.g., the determinant of a matrix. sage: a = matrix(...) sage: a.det? docstring about integer! And the above just makes absolutely no sense. The user expects to get a docstring about a function that computes the determinant, but instead they get the same docstring as "5?" would give. Yes, there is a function behind the scenes (that computes det), and it's possibly to get a docstring for it. I don't know how to make "a.det?" give that doctring though. Another issue is that frequently in math we have algorithms/options to functions, e.g., sage: a.det(algorithm="padic") Expressing the above with properties is awkward and hard to discover. What's worse is maybe you can only think of one way to compute det, so sage: a.det to compute det is fine. But then somebody *later* things of another algorithm, and you have to completely break all code that used det. Also, computable properties are annoying since it makes it harder to see why code is slow, e.g., sage: a.det * b.det ... no function calls, so fast, right? No. So we didn't end up embracing properties in Sage, purely because they aren't friendly toward the above use cases. For non-interactive more library oriented Python programming I think properties can be extremely useful (are they used even once in all of Sage anywhere?). But for interactive Sage use, I was dubious when they were introduced long ago. -- William > >> Python's primary mechanism for storing information on instances is via >> attributes stored in the instance __dict__. Do we really want to dissuade >> people from using the most straightforward storing method by default? The >> "consenting adults" doctrine of Python suggests we shouldn't do that just to >> enforce immutability. > > > The underscore is a convention, nobody stops you from ignoring it. But at > least you have been warned. There is a difference between "we are consenting > adults" and having everything filled with glass shards. > > -- > 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 http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
