#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.2
Component: categories | Resolution:
Keywords: days54 | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Simon King, Frédéric
Report Upstream: N/A | Chapoton
Branch: | Work issues:
public/ticket/10963-doc- | Commit:
distributive | 5c9ac79fb7207b179fc3717570fb078f40d526a0
Dependencies: #11224, #8327, | Stopgaps:
#10193, #12895, #14516, #14722, |
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506, |
#15757, #15759 |
-------------------------------------+-------------------------------------
Comment (by darij):
Part 2: the beginning of `sage/categories/category_with_axiom.py`.
- I don't understand this:
{{{
- From an object oriented point of view, any subcategory ``Cs()``
of :class:`~sage.categories.sets_cat.Sets` inherits from a
``Finite`` method, and ``Cs``
can complement this method with extra data (here a mixin class)
in the form of a class attribute ``Cs.Finite``.
}}}
"inherits from" should be "inherits", right? What does "extra data (here a
mixin class)" mean? Should a class attribute (not a class method) really
override a method? Or does "class attribute" mean "class method" here? And
what does this paragraph actually say? That I can override any method from
a higher-up category? Isn't that clear anyway?
- This reads weird:
{{{
This is undoubtedly a code smell. Nethertheless it should be kept as
is, first to resolve the import order properly, and more
importantly as a reminder that the category would be best not
constructed upon Sage's startup. This to entice developpers to
reduce the number of parents (and therefore categories) that are
constructed upon startup. Each "at_startup=True" that will be
removed will be a measure of progress in this direction.
}}}
"it should be kept as is" probably was intended to mean that the warnings
at startup time should be preserved, not that the lazy import at startup
time should be preserved. I don't understand the use of "entice" in this
paragraph.
- I don't understand this:
{{{
.. NOTE::
In principle, due to a limitation of :class:`LazyImport` with
nested classes (see :trac:`15648`), one should pass the option
``as_name`` to :class:`LazyImport`::
Finite = LazyImport('sage.categories.finite_groups',
'FiniteGroups', as_name='Finite')
in order to prevent ``Groups.Finite`` to keep on reimporting
``FiniteGroups``.
Given that passing this option introduces some redundancy and is
error prone, the axiom infrastructure includes a little workaround
which makes the ``as_name`` unnecessary in this case.
}}}
But it sounds like something that can eventually bite me in the ass. Can I
have some more detail?
- Line 251:
{{{
We don't recommend using this syntax which may eventually be
deprecated.
}}}
What syntax? `Algebras.WithBasis(QQ)`? What is the general pattern here
(other than "declaration of base needlessly delayed")?
- My 2 cents on one of the pain-in-the-ass issues: I do *not* oppose the
syntax-based guessing of base category class and axiom, as long as it is
used as a last resort and can always be manually overridden if it turns
out to be less than smart. After all, am I seeing it right that if it
*does* return a guess, the guess is guaranteed to be correct (`assert
getattr(base_category_class, axiom, None) is cls`)? If this is indeed the
case, you should proudly point this out in the documentation, because
"heuristic" and "guesses" are words that make people like myself very
scared. (Also, maybe add some instructions for users of categories on how
to add doctests that verify that it is successful at guessing?)
- Why talk of arborescences rather than just rooted trees? Do you want to
stress a poset/digraph structure?
- Wait...
{{{
For example, the fact that a cartesian product of associative magmas
(i.e. of semigroups) is associative
}}}
Really? Isn't that the typical associativity-up-to-equivalence situation
where the equivalence can usually be ignored in proofs but comes back with
a vengeance if taken too lightly in code? Specifically, is ((1,2),3) ==
(1,(2,3)) ?
I'll have to stop here because I want to update sage to beta4. The new
commit I'm pushing is mostly harmless doc edits, and I hope they won't
take long to review.
The doc still is very good!
----
New commits:
||[http://git.sagemath.org/sage.git/commit/?id=5c9ac79fb7207b179fc3717570fb078f40d526a0
5c9ac79]||{{{more doc fixes}}}||
----
New commits:
||[http://git.sagemath.org/sage.git/commit/?id=5c9ac79fb7207b179fc3717570fb078f40d526a0
5c9ac79]||{{{more doc fixes}}}||
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:566>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
