> What bad practice are you referring to? The output of some functions are > lists where the ordering is somewhat unpredictable. This different > ordering can reveal itself in testing on different platforms, or with a > changed package that Sage depends on. Yet for a user looking at the > examples of using such a function, it's nicer to see > > sage: my_func(inputs) # unordered > [A, C, B] > > rather than > > sage: set([str(c) for c in my_func(inputs)]) == set(["A","B","C"]) > True > > David >
Agreed. This is especially true for the Matroid class, where the ground set can contain any hashable objects. The automatic label generator for extensions will go for strings, so it's easy to get a mixture of strings and integers. --Stefan. P.S. The Graph class does way too much sorting. See e.g. sage.graphs.generic_graph.GenericGraph.vertices() -- 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.
