I've created #20904 to deprecate the Matrix.I property which is ready for
review.
This seemed to be the only case that most people agreed was bad. There
remains Matrix.T and Matrix.H as well as a handful of other public API
properties scattered randomly across Sage.
Best,
Johan
--
You receiv
On Wed, May 4, 2016 at 10:07 PM, Johan S. R. Nielsen
wrote:
> Michael Orlitzky writes:
>> I have a matrix m... how come,
>>
>> * m.rank gives me bullshit
>> * m.rank() works
>> * m.T() crashes
>> * m.T works?
>
> This is in my mind the most compelling reason to phase out properties in
> Sa
On Thu, May 5, 2016 at 9:41 AM, Jason Grout wrote:
> FYI, a relevant post just appeared on the ipython dev list:
> https://mail.scipy.org/pipermail/ipython-dev/2016-May/017099.html
>
Indeed! I'm delighted by this, and as mentioned here (
https://mail.scipy.org/pipermail/ipython-dev/2016-May/0171
FYI, a relevant post just appeared on the ipython dev list:
https://mail.scipy.org/pipermail/ipython-dev/2016-May/017099.html
A few minutes ago we merged a PR[1] adding jedi[2] integration to
IPython, this make the IPython completer a bit smarter,
as it now knows about situation like:
In[1]: ('
[X] Phase out properties which perform any non-trivial computation, and
officially condone the use of properties as "getters" of trivial
private information.
Best, Clemens
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe fro
On Wed, May 4, 2016 at 1:07 PM, Johan S. R. Nielsen
wrote:
> Michael Orlitzky writes:
>> I have a matrix m... how come,
>>
>> * m.rank gives me bullshit
>> * m.rank() works
>> * m.T() crashes
>> * m.T works?
>
> This is in my mind the most compelling reason to phase out properties in
> Sag
Michael Orlitzky writes:
> I have a matrix m... how come,
>
> * m.rank gives me bullshit
> * m.rank() works
> * m.T() crashes
> * m.T works?
This is in my mind the most compelling reason to phase out properties in
Sage. I think Erik makes many good points, but ultimately I think
consistenc
William Stein writes:
> 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 payin
On May 4, 2016 5:49 PM, "Erik Bray" wrote:
>
> On Wed, May 4, 2016 at 4:28 PM, William Stein wrote:
> > On Wed, May 4, 2016 at 7:18 AM, Erik Bray wrote:
> >> On Wed, May 4, 2016 at 4:06 PM, William Stein wrote:
> >>> On Wed, May 4, 2016 at 6:13 AM, Erik Bray
wrote:
> >>> [...]
> Anyways w
On Wednesday, May 4, 2016 at 3:13:21 PM UTC+2, Erik Bray wrote:
>
> I don't think it's just "syntactic sugar". If anything it's setter
> and *especially* getter methods that are backwards, but unfortunately
> necessary in languages like Java that don't have a natural way to
> interpose in attri
I see. However, as I said before, there are good reasons why that is not
the default behaviour.
El miércoles, 4 de mayo de 2016, 17:50:41 (UTC+2), Volker Braun escribió:
>
> On Wednesday, May 4, 2016 at 5:26:03 PM UTC+2, mmarco wrote:
>>
>> Overall, I think that the problem with documentation is
On Wed, May 4, 2016 at 5:26 PM, mmarco wrote:
> 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 tab compl
On Wednesday, May 4, 2016 at 5:26:03 PM UTC+2, mmarco wrote:
>
> 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]
>
You can do that already:
sage: n = matrix(Q
On Wed, May 4, 2016 at 4:28 PM, William Stein wrote:
> On Wed, May 4, 2016 at 7:18 AM, Erik Bray wrote:
>> On Wed, May 4, 2016 at 4:06 PM, William Stein wrote:
>>> On Wed, May 4, 2016 at 6:13 AM, Erik Bray wrote:
>>> [...]
Anyways we can agree to disagree on this, and even within the Pytho
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
On 05/04/2016 09:13 AM, Erik Bray wrote:
>
> I call it premature encapsulation.
>
We can agree there. But when you're programming on a team, the hardest
part is making sure everyone else doesn't do anything stupid. And in the
Java/C# world, half of the team is 22 years old and writing their firs
On Wed, May 4, 2016 at 7:18 AM, Erik Bray wrote:
> On Wed, May 4, 2016 at 4:06 PM, William Stein wrote:
>> On Wed, May 4, 2016 at 6:13 AM, Erik Bray wrote:
>> [...]
>>> Anyways we can agree to disagree on this, and even within the Python
>>> community you'll find different opinions, especially r
On Wed, May 4, 2016 at 4:06 PM, William Stein wrote:
> On Wed, May 4, 2016 at 6:13 AM, Erik Bray 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 d
On Wed, May 4, 2016 at 6:13 AM, Erik Bray 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 exception
On Tue, May 3, 2016 at 4:25 PM, Michael Orlitzky wrote:
> On 05/03/2016 09:22 AM, Erik Bray wrote:
>>
>> You seem to have this view that the sole purpose of getter and setter
>> methods is to update a private member of some object. Am I
>> understanding that correctly? Because either I'm misunder
On 05/03/2016 09:22 AM, Erik Bray wrote:
>
> You seem to have this view that the sole purpose of getter and setter
> methods is to update a private member of some object. Am I
> understanding that correctly? Because either I'm misunderstanding
> you, or you seem to be confused about why property
On Tue, May 3, 2016 at 3:04 PM, Michael Orlitzky wrote:
> On 05/03/2016 03:51 AM, Erik Bray wrote:
>>
>> I can say from significant experience that that is *not* the only
>> useful feature of property.
>>
>> Let's also not forget the even deeper magic that is the descriptor
>> protocol in general.
On 05/03/2016 03:51 AM, Erik Bray wrote:
>
> I can say from significant experience that that is *not* the only
> useful feature of property.
>
> Let's also not forget the even deeper magic that is the descriptor
> protocol in general.
>
Well, what's the other useful feature? It lets you call me
On Mon, May 2, 2016 at 6:26 PM, Michael Orlitzky wrote:
> On 05/02/2016 06:07 AM, Erik Bray wrote:
>> On Mon, May 2, 2016 at 10:35 AM, Jeroen Demeyer
>> wrote:
>>> My vote:
>>>
[X] Phase out properties which perform any non-trivial computation
>>>
>>>
>>> In certain cases, properties might
On Monday, May 2, 2016, Michael Orlitzky wrote:
> On 05/02/2016 06:07 AM, Erik Bray wrote:
> > On Mon, May 2, 2016 at 10:35 AM, Jeroen Demeyer > wrote:
> >> My vote:
> >>
> >>> [X] Phase out properties which perform any non-trivial computation
> >>
> >>
> >> In certain cases, properties might be
On 05/02/2016 06:07 AM, Erik Bray wrote:
> On Mon, May 2, 2016 at 10:35 AM, Jeroen Demeyer
> 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
> Consistency is a definitive plus, as well as not impeding
> introspection. So I would tend to agree to officially phase out
> properties from the public API.
>
> There is one use case for properties in the public API though which I
> would like to bring up, namely "glorified methods".
> ...
Yes,
On Mon, May 2, 2016 at 10:35 AM, Jeroen Demeyer 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*
On 2016-04-29 10:38, Nicolas M. Thiery wrote:
P.f(x) # use the morphism as a function
P.f.rank() # play with the morphism itself
cached method also does this.
You can do P.f(x) to call the cached_method f but you also do stuff like
P.f.clear_cach
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).
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsu
> Wouldn't you have to get rid of all public attributes as well when doing
> this?
> Or why should
> sage: x.some_attribute
> work and
> sage: x.some_attribute_by_at_property
> be forbidden?
My impression is that public attributes generally are frowned upon, in
Sage as in many other projec
On Fri, Apr 29, 2016 at 09:31:31AM +0200, Johan S. R. Nielsen wrote:
> I call for the following vote:
>
> [ ] Phase out all uses of properties in the public API and make them
> into methods that take no arguments. Add in the developer's manual
> somewhere that this is the general policy.
>
On 2016-04-29 09:31, Johan S. R. Nielsen wrote:
> [ ] Phase out all uses of properties in the public API and make them
> into methods that take no arguments. Add in the developer's manual
> somewhere that this is the general policy.
Wouldn't you have to get rid of all public attributes as
In the previous discussion concerning properties on Matrix, there seemed
to be consensus that Matrix.I was a problem. More generally, only
little defence of the general use of properties in the public API was
given.
Therefore, I suggest that we phase out *all* uses of properties in the
public API.
34 matches
Mail list logo
