#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 nthiery):
Replying to [comment:458 vbraun]:
> 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` mechanism is more general
in that it allows to express implications (C1+A1+A2 => C2+A3) in addition
to relations.
Or even C1+A1+A2 -> C3.
Another plus side is that it gives a natural spot (the docstring of
the method) to document and test the modeling of the theorem.
> (I agree with the sentiment that there ought to be better names)
Definitely! We have been using `extra_super_categories` since 2009.
If someone has a suggestion for a better name it should be easy to
change it now or later while maintaining temporary backward
compatibility.
> 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.
And I would have definitely voted against it :-)
Now let me recall that the guessing based on the name only occurs to
enable the alias FiniteSets() -> Sets().Finite(). If you do
Sets().Finite() directly, it's not used at all. So it's just about
implementing a syntactic sugar, not about semantic.
In fact, I am not even sure we want to have that syntactic sugar at
all in the long run. My main motivation for implementing it was for
backward compatibility. Later on, I definitely want to remove quite
some of the names like GradedAlgebrasWithBasis from the global name
space. Probably FiniteSets / FiniteGroups / ... too. And possibly
completely deprecate the idiom FiniteSets(). Of course, we definitely
want to keep Fields(), Groups(), ... but those don't use the guessing
anyway.
Yes, yes Volker, that intention was yet not spelled out explicitly; I
once again relied on your telepathic abilities :-) I'll add now a
comment in the documentation about the recommended usage of
Sets().Finite() and the potential deprecation of FiniteSets().
Btw: I don't want to handle this deprecation phase right now because
there is already enough on the plate of this ticket and because I
believe we need to have people play around with the code before
deciding how far we want to do the deprecation.
Altogether, I believe that for implementing a syntactic sugar, that
further might be temporary or for which we can seek later another
solution, a little guess work is not great but ok.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:463>
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.
