That is a good example of why using @property might fit bad with the usual sage workflow. On the other hand, there are other examples that could show how it actually might fit better:
sage: n = matrix(QQ, 2) sage: n.T.[tab] And the user gets the list of the methods he can call on the traspose of n. For the user that already knows what T does, it would be convenient to tab-complete on the fly, without needing to store n.T() in a new variable and tab-complete on it. Overall, I think that the problem with documentation is worse than the gain with tab-completion, but it would be so nice if we could do something like: sage: n.transpose().[tab] and get the corresponding methods shown. One would be tempted to modify ipython in order to get a function called whenever a tab complition is asked like in sage: foo.bar().[tab] but that could have dangerous side effects if calling bar() mutates foo in some way (or injects something to the namespace, or...). El miércoles, 4 de mayo de 2016, 16:29:38 (UTC+2), William escribió: > > On Wed, May 4, 2016 at 7:18 AM, Erik Bray <erik....@gmail.com > <javascript:>> wrote: > > On Wed, May 4, 2016 at 4:06 PM, William Stein <wst...@gmail.com > <javascript:>> wrote: > >> On Wed, May 4, 2016 at 6:13 AM, Erik Bray <erik....@gmail.com > <javascript:>> wrote: > >> [...] > >>> 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. > >> > >> The Sage library tends to be used differently than a lot of Python > >> code. The distinction is that most Sage code is really meant to be > >> used interactively from a command prompt. This is why doctests work > >> so well for us, instead of unit tests, which work much better than > >> doctests for many other projects. The typical usage pattern in Sage > >> is (1) make foo, (2) foo.[tab], (3) foo.bar exists -- cool! what does > >> it do? (4) foo.bar?. This is dramatically different than the > >> typical usage pattern of many Python libraries/programs (e.g., a > >> django webserver). > > > > That's how I try to write most code anyways, since most of the code I > > write these days is for consumption of the unintentional developer. > > They're "users" in so far as they only want to use my code to build > > their own code to get some kind of result. But they're still > > developers because the interface I'm offering them is in the form of > > objects they can manipulate using a general purpose programming > > language. It's good because it really does force you to think about > > encapsulation in a practical way. "What attributes and methods do I > > want to expose?", "What are just implementation details?" > > > > If anything I think "Pythonic" idioms work well for this kind of > > usage. I don't see any contradiction here. > > Let's say we use properties a lot: > > (1) make an integer n > (2) n.[tab], > (3) n.bar exists -- cool! what does it do? > > Then: > > (4) n.bar? > > results in either: > > (a) a nice docstring about the bar method > (b) a potentially long computation of n.bar, and then the docstring > for pretty much anything, e.g., if n.bar? is an integer, you get the > docstring for an integer, not for what bar is. > > If (b) every happens to me when using Sage, I will frankly be confused > and pissed. > > I'm just going to be a little blunter. This session below is *STUPID*: > > sage: n = matrix(QQ,2) > sage: n.det? # good output > Docstring: > Synonym for self.determinant(...). > > EXAMPLES: > > sage: A = MatrixSpace(Integers(8),3)([1,7,3, 1,1,1, 3,4,5]) > sage: A.det() > sage: n.T? # output -- WTF? > Type: Matrix_rational_dense > String form: > [0 0] > [0 0] > File: > /projects/sage/sage-6.10/local/lib/python2.7/site-packages/sage/matrix/matrix_rational_dense.pyx > > > Call docstring: > Calling a matrix returns the result of calling each component. > > EXAMPLES: > > sage: f(x,y) = x^2+y > sage: m = matrix([[f,f*f],[f^3,f^4]]); m > [ (x, y) |--> x^2 + y (x, y) |--> (x^2 + y)^2] > [(x, y) |--> (x^2 + y)^3 (x, y) |--> (x^2 + y)^4] > sage: m(1,2) > [ 3 9] > [27 81] > sage: m(y=2,x=1) > [ 3 9] > [27 81] > sage: m(2,1) > [ 5 25] > [125 625] > > > --- > > Unless the above messed up dichotomy is fixed in every possible way > people might use Sage interactively, I'm personally 100% against using > properties for objects users interact with at the top level. They > have only snuck in in a couple of places because I wasn't paying > attention. > > -- William > > > > > -- > William (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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
