Hey Simon, On Tuesday, July 30, 2013 9:18:28 PM UTC+9, Simon King wrote: > > Hi all, > > On 2013-07-29, Simon King <simon...@uni-jena.de <javascript:>> wrote: > > After all, we have a class, and we call the class as if to create an > > instance---but what we get is in fact not an instance of this class, but > > is instance of a *totally* different class. > > > > OK, it is possible, Python let's you do it. But not all what can be done > > should be done. > > > > I have nothing against the following pattern: > > > > ... > > > > And I think this pattern is totally fine, since C(...) returns instances > > of sub-classes of C (namely of A resp. B)---hence, it returns instance > > of C! I could imagine that a similar pattern would be available for > > Partition versus PartitionTuple. > > I determined all classes-with-ClasscallMetaclass that sometimes return > instances that are not instances of this class: > sage.combinat.composition.Compositions > > > sage.combinat.integer_vectors_mod_permgroup.IntegerVectorsModPermutationGroup > > sage.combinat.partition.Partitions > sage.combinat.partition_tuple.PartitionTuple > sage.combinat.posets.poset_examples.Posets > sage.combinat.root_system.type_relabel.CartanType > sage.combinat.tableau_tuple.StandardTableauTuple > sage.combinat.tableau_tuple.StandardTableauTuples > sage.combinat.tableau_tuple.TableauTuple > sage.combinat.tableau_tuple.TableauTuples > plus three classes that seem only to be made for doctests. > > What do you think? These are relatively few classes. Would it be > reasonable to change them, such that when on tries to create instances > of these classes then one is guaranteed to actually get an instance of > these classes (or a sub-class, at least)? > This part is for the parent classes. As it stands, the return type is something that behaves like the object you expect, so it still walks like a duck and quacks like a duck, even if it is not a duck. I don't like factory functions since you call Permutations(blah) and get an object of type Permutations_class, which make the code more difficult to understand wrt type-checking. However I'm okay with adding an extra level of abstract classes (which are probably just going to be a marker interface, i.e. have no methods/attributes) since it gives it a unifying type-check. For the element classes, this is more tricky since the data structure changes depending upon input, but this isn't strictly a bad thing. For example, if creating a complex number returned a real number if the imaginary part is 0, this should be okay because we might want to know it is a real number and take advantage of more specialized methods/algorithms. In the case of the tuples, a partition/tableau 1-tuple behaves exactly like a usual partition/tableau resp. so it doesn't seem like so much of a surprise that it returns an honest partition/tableau. Overall, I'm not convinced that __classcall__() should force its return to be a subclass of itself, but I'm okay with labeling the practice as "evil".
Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
