#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.1
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 | Commit:
Dependencies: #11224, #8327, | eb7b486c6fecac296052f980788e15e2ad1b59e4
#10193, #12895, #14516, #14722, | Stopgaps:
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by SimonKing):
Replying to [comment:426 vbraun]:
> I also think that the code on this ticket suffers from a lot of abuse of
lazy imports. They are a useful tool, but they don't absolve you from
thinking about import order of modules.
Perhaps I misunderstand, but to me it seems the lazy imports are used in
order to avoid that ''all'' category classes are imported at startup time:
`PermutationGroups.Finite` should only be imported when it is actually
needed, but not if you only intend to use `PermutationGroups`. Yet it
should show up as an attribute. Do you think that, on top of that purpose,
it is used to break import cycles?
> In particular, lazy imports that you have to resolve on startup are IMHO
a sure sign of code smell.
Sounds right. If something is imported at startup time anyway, then why
should one not use a proper import?
> > Either you define MyAxiom in a location of its own. But then you
> > loose some code locality (the code for the axiom is not tied to
> > the category defining it, which I find important).
>
> But axioms are **not** tied to particular categories. They can be added
to categories, but there is no need to have a unique "most basic category"
for the axiom.
As I have mentioned earlier, it is simply a fact that you always have a
"most basic category". Namely, it is the category that provides all
notions that you need in order to formulate the axiom. E.g.,
`AdditiveMagmas` when you want to formulate `x+y==y+x`.
> You are deliberately omitting the other half of the story: If you have
two unrelated classes `C` and `D` then `C.a` and `D.a` are unrelated in
Python. And you are breaking that.
Well, if `a` is an axiom and `C` and `D` are categories and if `a` can be
formulated in both `C` and `D`, then they are both sub-categories of the
largest category `B` that allows to formulate `a`. In this sense, `C` and
`D` ''are'' related.
And that's another argument for considering the "most basic category
allowing to formulated an axiom": It is natural (when you think of Python
classes) to provide `a` as an attribute of `B`, and then `C` and `D` both
inherit `B.a`. That said, it could very well be that because of some
theorems axiom `a` implies properties of `C.a()` that are not part of what
is provided by `B.a()`. And that's when (in Python) you would override
`B.a` in `C`.
But actually that's not the end of the story yet. We can provide `a` with
a `__get__` method that does recognise whether `a` is bound to `B` or to
`C`, and so we could make it so that `C.a` earns additional features that
are not in `B.a`.
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:428>
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/groups/opt_out.
