#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 vbraun):
Replying to [comment:457 SimonKing]:
> implementing the theorem is fairly straightforward after learning the
rules
Well I agree that it works, but I don't think the implementation of the
relation As+B+C = As+E+F is as concise as it could be phrased.
On the plus side, the `extra_super_categories` (I agree with the sentiment
that there ought to be better names) mechanism is more general in that it
allows to express implications (C1+A1+A2 => C2+A3) in addition to
relations.
> What would the same programmer say about the abc module?
It precisely requires you to link, in code, your ABC to the virtual
subclass:
{{{
FooABC.register(Foo)
assert isinstance(Foo(), FooABC)
}}}
PEP 3119 could have said that Foo is automatically registered as virtual
subclass of FooABC if there is a class of that name. This would have saved
a line of code, but was afaik not even considered for the standard.
> I said that it only seemed unnecessary to me ''at first''! And after
all, the necessity to choose a spanning tree makes it fairly obvious that
one has to make choices at some point.
Yes, I agree that one must make choices. But some of the choices are
inconsequential, why should I care about A.B.C vs A.C.B? Why am I forced
to pick? There is already a total order on axioms implemented, can't that
already be used to break the symmetry?
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:458>
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.
