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 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.
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". > ... Yes, this is a good example of where such syntactic micro-magic can be a very pleasant experience for the user. I think the cases of properties that both Jeroen and Erik are arguing to allow are exactly things like this. It seems that possible doc-issues can be managed, more or less. So I concede that the rigid stance of officially disallowing all properties would be "asking for trouble". Perhaps a more realistic stance is something like: [ ] Rule of thumb: don't use properties, except if there is a clear, syntactic benefit that presents a logical exception (to the "method default") for the user. Properties should particularly be avoided if exceptions could be thrown or heavy computation performed. OK, so that's not perfectly well-defined either, but at least things like MPolynomialIdeal.basis should be method'ized by this rule, as should the list of properties in the recent AsymptoticRing class (e.g. summands, growth_group, coefficient_ring, ao.). Going back to Matrix, I would argue that Matrix.T, Matrix.H, etc. also fall for this rule. Certainly, Matrix.I does. Best, Johan -- 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.
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 that properties *should* be used in general for invariants of some object, regardless of how it's computed in the first place. I see the point about not using them for "non-trivial" computations but I also find the lack of a clear definition of "non-trivial" troubling. I agree with Jeroen that there may be exceptions. I think a strict rule against "properties in public APIs" is asking for trouble, and that this should still be considered on a case-by-case basis. Perhaps more controversially, I'm fond of creating proxy objects that can become callable if need be For example an int that usually has an invariant value, but in might rare cases can be modified by some additional context that would be provided by "calling" it, in which case I make a proxy-int that's callable. I think in these cases Sage's policy has been to make them methods with zero required positional arguments, which is fine too. It's my preference, but it also has downfalls, so it's not a sword I care to die on :) Erik -- 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.
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 P.f.clear_cache(). I certainly do not want cached methods to become P.f()(x). -- 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.
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 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.
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 projects and languages. Best, Johan -- 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.
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. > > [ ] Phase out properties which perform any non-trivial computation, and > officially condone the use of properties as "getters" of trivial > private information. > > [ ] Phase out properties that might (expectedly) throw exceptions, such > as Matrix.I. Condone the use of properties as "getters" of derived > information, such as Matrix.T (transpose). > > [ ] Keep things as they are. > > > For the record, my vote is on phasing out all properties. 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". Let me explain: Let P be a parent, and f be a morphism naturally attached to P. Typical examples are P.product, P.coproduct, ... User wants to: - use the morphism as a function and apply it on elements - do operations on the morphism (e.g. compute its rank) In the current instances, the construction of the morphism may be non trivial (e.g. define the morphism by linearity), but is cheap (at the scale of user interaction, e.g. tab completion), and does not raise exceptions (unless the code is broken in the first place). In several places, we have used the following convention: P.f(x) # use the morphism as a function P.f.rank() # play with the morphism itself To achieve this, P.f is actually a property (typically a lazy_attribute), that constructs the morphism. Alternative syntaxes would be: P.f()(x)# use the morphism as a function P.f().rank()# play with the morphism itself P.f(x) # use the morphism as a function P.f_morphism().rank() # play with the morphism itself The merits of the syntax we use are: - For beginners P.f just feels like as a usual method. When they need more, they can realize that P.F is actually more than a method - We don't pollute P's namespace with two gadgets for just one thing. This is a use case of properties in the public API which I would like to keep as an exception. Other exceptions of course are the usage of properties for implementing meta-stuff, like cached_methods, abstract methods, conditionally defined methods, etc. I don't have a strong opinion about properties for private attributes. It seems reasonable indeed to request that they should not raise exceptions nor do lengthy computations. Cheers, Nicolas -- Nicolas M. ThiƩry "Isil" http://Nicolas.Thiery.name/ -- 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.
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 well when doing this? Or why should sage: x.some_attribute work and sage: x.some_attribute_by_at_property be forbidden? Daniel -- 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.
[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 API. The main reasoning is consistency: we are much more ubiquitously using methods to get information on objects, and it is inconsistent, confusing and unnecessary to use properties in arbitrary places, just to save a two keystrokes. I grep'ed for @property and found no instances of public properties that could not easily be methods instead (*). Some cases are even super-inconsistent, such as MPolynomialIdeal.basis (basis() is a method on all other classes I know of). 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. [ ] Phase out properties which perform any non-trivial computation, and officially condone the use of properties as "getters" of trivial private information. [ ] Phase out properties that might (expectedly) throw exceptions, such as Matrix.I. Condone the use of properties as "getters" of derived information, such as Matrix.T (transpose). [ ] Keep things as they are. For the record, my vote is on phasing out all properties. There is a technical problem with how to issue proper deprecation warnings. One possibility is to insert deprecation warnings now for >1 year, and then do the change at a major version. But I think it's more important to decide how extensively we want to change things first. Best, Johan (*): Simon King hinted earlier at possible performance degradations, though. I don't know much about this. -- 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.