Re: [sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API

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 (

Re: [sage-devel] Deprecate the use of properties in all public API

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]:

Re: [sage-devel] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)

[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

Re: [sage-devel] Deprecate the use of properties in all public API

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

[sage-devel] Deprecate the use of properties in all public API

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

[sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API

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:

Re: [sage-devel] Deprecate the use of properties in all public API

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 =

Re: [sage-devel] Deprecate the use of properties in all public API

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:

Re: [sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API

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?

Re: [sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API

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

Re: [sage-devel] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)

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

Re: [sage-devel] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)

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

Re: [sage-devel] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)

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

Re: [sage-devel] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)

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

Re: [sage-devel] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)

> 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

Re: [sage-devel] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)

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.

Re: [sage-devel] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)

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

[sage-devel] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)

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