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 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.
