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

[Clemens Heuberger]

[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)

[Johan S . R . Nielsen]

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

[Erik Bray]

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)

[Jeroen Demeyer]

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)

[Jeroen Demeyer]

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)

[Johan S . R . Nielsen]

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

[Nicolas M. Thiery]

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)

[Daniel Krenn]

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.