Hi folks,
On 10 Okt., 15:53, Nicolas M. Thiery nicolas.thi...@u-psud.fr
wrote:
On Mon, Oct 10, 2011 at 05:36:29AM -0700, Simon King wrote:
Is there a ticket for a related topic that is marked FixMe in sage/
categories/category.py: Use Python's method resolution order in
Hi all!
Make parent/element classes independent of the base ring (unless
absolutely necessary) is #11935, needing review. There are two
patches, providing two different implementations. So, pick one, if you
like.
There is no ticket for Make all_super_categories consistent with
parent_class.mro()
On Mon, Oct 10, 2011 at 07:18:12AM -0700, Simon King wrote:
Probably it isn't. The only thing that people on sage-devel pointed me
to was a function implemented in C that assumes to receive a list of
types. Thus, even when wrapping it in Cython, one couldn't apply it to
lists of categories.
Hi Nicolas,
On 11 Okt., 12:25, Nicolas M. Thiery nicolas.thi...@u-psud.fr
wrote:
Ok. This can be a good occasion to detect early on when there is a
conflict in the category inheritance diagram, and try to raise a more
meaningful message than MRO conflict.
Yep! That's one of the positive side
Hi all!
Is there already a ticket for the problem discussed here (Make
parent_class and element_class independent of the base ring, whenever
possible)?
Is there a ticket for a related topic that is marked FixMe in sage/
categories/category.py: Use Python's method resolution order in
On Mon, Oct 10, 2011 at 05:36:29AM -0700, Simon King wrote:
Is there already a ticket for the problem discussed here (Make
parent_class and element_class independent of the base ring, whenever
possible)?
Is there a ticket for a related topic that is marked FixMe in sage/
Hi Nicolas,
On 10 Okt., 15:53, Nicolas M. Thiery nicolas.thi...@u-psud.fr
wrote:
Speaking of the latter, +1 on using directly Python's implementation
if at all possible.
Probably it isn't. The only thing that people on sage-devel pointed me
to was a function implemented in C that assumes to
On Fri, Oct 07, 2011 at 01:30:49PM -0700, Simon King wrote:
I really don't see the problem.
On 7 Okt., 22:21, Simon King simon.k...@uni-jena.de wrote:
So, why shouldn't parent_class rely on the generic pickling of a
dynamic class? Well, I guess I should simply try and look how it blows
Hi Nicolas,
Sorry, I have seen your post only now.
On 7 Okt., 23:06, Nicolas M. Thiery nicolas.thi...@u-psud.fr
wrote:
It would not be quite surprising if the pickling of classes made some
progress since 2009 :-) However, just to make sure: please save the
pickle to a file, and reload it in a
Hi Nicolas,
On 8 Okt., 17:40, Simon King simon.k...@uni-jena.de wrote:
I know a trick that combines the old way of pickling with the desired
independence from the base ring:
1. The lazy attribute C.parent_class could start with constructing a
dynamic class without specifying the reduction
I really don't see the problem.
On 7 Okt., 22:21, Simon King simon.k...@uni-jena.de wrote:
So, why shouldn't parent_class rely on the generic pickling of a
dynamic class? Well, I guess I should simply try and look how it blows
up...
I simply dropped the reduction data from the definition of a
On Fri, Oct 07, 2011 at 10:38:49AM -0700, Simon King wrote:
But here, I'd like to have the answer True:
sage: Algebras(GF(3)).parent_class is Algebras(GF(5)).parent_class
False
+1
Short summary: sharing those classes was my original intent; see the
discussion around line 240 of
12 matches
Mail list logo
