On 16/02/2020 9:09, Michael Orlitzky wrote:
On 2/15/20 9:33 PM, Kwankyu Lee wrote:
It would also be mildly confusing to allow both of these
from sage.coding.punctured_code import PuncturedCode
PuncturedCode(...)
and
codes.punctured_code(...)
So your suggestion would imply that we should discourage users from
using the former style. Then that we don't have
R.<x> = rings.polynomial_ring(QQ)
but only
R.<x> = PolynomialRing(QQ)
would confuse some users.
I wrote a rather long response to this about the design decisions that
go into a programming language versus those that go into a discoverable
end-user interface, and about how we have to live with some confusion
because of the python ClassName convention... but then I realized that
PEP8 already says you can use lowercase for class names:
Class names should normally use the CapWords convention. The naming
convention for functions may be used instead in cases where the
interface is documented and used primarily as a callable.
- https://www.python.org/dev/peps/pep-0008/#class-names
So yes, let me internally adopt the more radical stance =)
In the future, classes like FiniteDimensionalAlgebra, whose constructors
are the primary (documented!) user-interface to that class, should use
the lowercase-with-underscores function naming scheme. Since it's legal
in python, we should do it so that our users don't have to guess whether
or not the first letter of the thing they want is capitalized.
Obviously this would take forever to gain traction (and would face a lot
more resistance), but it's a nice thought. In the meantime, regardless
of whether or not anyone agrees with that for true constructors, I don't
think we should perpetuate the issue into settings like cones.<tab>
where there's no historical technical reason to do so.
I think the name currently used in the docs for most of these factory
objects/modules is "catalog". Searching the docs [1] gives catalogs for
algebras, crystals, groups (with sub-catalogs), manifolds, codes,
designs, matroids, posets and others.
There are classes like SymmetricGroup, whose name is well-known and was
set a long time ago. This is also the spelling in GAP and Magma, FWIW.
One name that I think should be changed is CyclicPermutationGroup, to
CyclicGroup. If we can have groups.permutation.Symmetric and
groups.presentation.Symmetric without too much confusion, then cyclic
groups can follow the same naming convention.
Regards,
TB
[1]
https://doc.sagemath.org/html/en/reference/search.html?q=catalog&check_keywords=yes&area=default
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/1e5a6a58-536d-c408-19ab-15e833fa7e40%40gmail.com.
