Hi, On Sat, Nov 23, 2013 at 04:30:04PM +0100, Harald Schilly wrote: > > (1) plot is already a specific command that means something, and is > > not obscure by any definition. > > I proposed "plots." (for me quite logical, since there is also > "groups."), sage.plot.* is also very good but not quite that ;-)
+1 for "plots.", though "graphics." could also make sense (wrt Graphics() constructor). Currently, none of plot<TAB> or sage.plot.<TAB> allows to discover implicit_plot, which i discovered by reading ask.sagemath.org. +1 also for "rings." and "fields.", even if we keep ZZ, QQ, AA,... in the global namespace as well, since they correspond to very standard objects. As well as with "plots.implicit", those will help the user to discover what is available in Sage. Having a unified naming scheme for constructors and related examples will ease teaching Sage. A single mechanism you can explain in 5 minutes is much better for the user's autonomy than a lot of shortcuts that maintain the user in manipulating magic recipes, even if those recipes seem appealing in a first discovery (for example the icosahedron() method plots an object that can not be manipulated further than having a fancy picture, but polytopes.icosahedron().plot() makes much more sense ; the same holds for circle() that returns a picture, not the plot of something that comes from a Curve() construction). I agree that it is somehow cool to be able to show some fancy things that work out of the box in Sage, so perhaps should we move those in a "demo." namespace ? We have a partial "Object()" "objects." correspondance for constructors and examples, that should be generalised: - Graph() graphs. - Matroid() matroids. - Word() words. - CubicalComplex() cubical_complexes. - Poset() posets. - ToricVariety() toric_varieties. - ... (the list is not exhaustive, i may have missed some) Some are less consistent and should be fixed: - Polyhedron() polytopes. (i prefer "Polytope() polytopes." over "Polyhedron() polyhedrons." since polyhedron is usually specific to dimension 3). - BlockDesign()/IncidenceStructure() designs. (note that "Design" is unused). - Matrix() matrix. (not matrices.). The other issue here is that "Matrix.<TAB>" gives you examples (as should "matrices." do). Also, matrix is equal to Matrix, so there is a useless redundancy which does not help. Moreover, it is incomplete, for example cartan_matrix or hadamard_matrix or coxeter_matrix are provided by a function, but not by Matrix.<TAB>. I propose to deprecate matrix and create matrices. with cartan, hadamard, coxeter... - SetSpecies/PartitionSpecies/SubsetSpecies/CombinatorialSpecies/ CharacteristicSpecies/SingletonSpecies/EmptySetSpecies/CycleSpecies/ LinearOrderSpecies/PermutationSpecies/EmptySpecies/SumSpecies/ ProductSpecies/CompositionSpecies/FunctorialCompositionSpecies species. Perhaps should there be a Species() overlay to all those ? That said, i understand the CamelCase/lowercase convention, but what explains the singular/plural one? Ciao, Thierry -- 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/groups/opt_out.
