Hi Florent, On 2014-03-08, Florent Hivert <florent.hiv...@lri.fr> wrote: >> The theory here is that Sets defines a Finite axiom, and by some metaclass >> magic the inner class Cs.Finite ends up being a subcategory of Sets.Finite. >> [...] >> Nicolas thinks this amount of breverity is a desirable feature, and I think >> we should make Cs.Finite be explicit about which axiom it implements (and, >> therefore, not require that it is named Cs.Finite if you don't want >> to). > > I completely second Nicolas on that point. There is a clash between Python's > > "explicit is better that implicit" > > and mathematical usage. ... > Now going back to Sage, I really think that if we don't keep the syntax *as > short as possible* (as in math: `let's G1, G2 be a finite commutative group > and Phi be a morphism from G1 to G2`) then this will be much to verbose to be > programmed with and each user will start to makes it's own shortcut which is > much worse.
I am not sure if Volker and you talk about the same meaning of "syntax". It seems to me that you take the position of a user, who has a category Cs() and wants to get the category of finite cs. Then, it is convenient if one can just do Cs().Finite(). This syntax is clear and simple. And I suppose that Volker agrees with you here. FWIW, *I* do. However, it seems to me that Volker was arguing from the position of a developer. Again, the nested class syntax seems nice and concise to me: sage: class Cs(Category): ....: def super_categories(self): ....: return [Sets()] ....: class Finite(CategoryWithAxiom): ....: class ParentMethods: ....: def foo(self): ....: print "I am a method on finite C's" But, as Volker has pointed out, the objects O of Cs().Finite() also inherit from the parent class of Sets().Finite(). There is no surprise from a mathematical point of view: O is a c and O is finite, every c is a set, the property "finite" applies to sets, thus O is a finite set. But is the mathematical syllogism really stated in the code in a sufficient level of clarity? Volker, do I understand correctly that this is your concern? My opinion on it, from a user perspective: - Yes, it is surprising for a novice user to see that O.is_finite() is available. If O.__class__ is a Cython extension class, you wouldn't even find an is_finite() method in O.__class__.mro(). But: This criticism also applies to the *existing* category framework. I don't think that the surprise will be worse with #10963. And as soon as one has understood what the category framework is about, the existence of O.is_finite() is *not* surprising. - A couple of years back, I did not like the category framework, since it was very difficult to find the source code of stuff. Now, introspection has improved, and `O.is_finite??` will show you the code. And with the possibility to easily find the source code, I started to find the category framework much easier to understand. My opinion, from a developer perspective: - I wouldn't implement a statistical tests, since I don't know about statistics. So, I suppose a developer who wants to implement a category knows about categories. - The code above clearly states that Cs() is a sub-category of Sets(). Thus, knowing about categories, the developer should not be surprised that applying the axiom "Finite" to Sets() is relevant for Cs().Finite(). However, something that I have mentioned earlier (and hasn't been answered yet) is the fact that sometimes Cs().Finite is not the class Cs.Finite, but is a cached method that is gotten by some black magic that I find not transparent, and (I think) for virtually no benefit. Nicolas, is documentation the only reason to make Cs().Finite be a cached method overriding Cs.Finite? Then I think we should find a different way to make Cs().Finite/Cs.Finite point the user to the specifications of the "Finite" axiom. Why not have a class method specification() for a CategoryWithAxiom C, that will print the documentation of the defining axiom of C (taken from where this axiom is defined)? Note that this documentation/specification problem could be solved by making axioms proper objects (that know about their specification!), rather than just strings. IIRC, Volker has provided a draft implementation. Best regards, Simon -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
