On May 4, 2016 5:49 PM, "Erik Bray" <erik.m.b...@gmail.com> wrote: > > On Wed, May 4, 2016 at 4:28 PM, William Stein <wst...@gmail.com> wrote: > > On Wed, May 4, 2016 at 7:18 AM, Erik Bray <erik.m.b...@gmail.com> wrote: > >> On Wed, May 4, 2016 at 4:06 PM, William Stein <wst...@gmail.com> wrote: > >>> On Wed, May 4, 2016 at 6:13 AM, Erik Bray <erik.m.b...@gmail.com> 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 a little confused about this, because it seems to be an issue with > how command-line interpreter is implementing tab-completion and help > lookup. > > I don't think "n.bar?" should first access "n.bar" through normal > attribute access, and then call help() on the result. In fact here I > agree with Michael that it's a very good place to use @property--it's > a clear way to define that a ".bar" attribute exists on instances of > whatever class "n" is an instance of, and provide documentation for > what its purpose is when accessed through normal attribute access. > (Where I disagree is the assertion that it's the *only* use of > property when the experience of an entire developer community would > suggest otherwise). > > > 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] > > Right, so apparently "?" isn't implemented well (I didn't realize this > was the case before), and offers little advantage over writing > help(n.T) other than in saved keystrokes.
(As an aside, I would tend to agree that matrix.T *should* be a method. But I also see M.T without parens as syntactic sugar itself, and a rough approximation of M^T, with which people are familiar. Perhaps exceptions like these are good uses for a lazily-evaluated proxy object, but I haven't thought through all the possible implications of that for something as complex as a matrix (most of the time I've only used these for built-in types likes int and str). -- 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.
