Categories for padics, schemes, and some more rings

[nthiery]

This patch fixes the following classes to use categories:

• padics
• RealLazyField?, ComplexLazyField?
• AlgebraicScheme?'s and subclasses

#11935 depends on this one

[SimonKing]

Hooray, finally the category of schemes is used in Sage! Question: Are there morphisms of schemes, yet? I am first reviewing #12875 and will then also look at the ticket here.

[nthiery]

Replying to SimonKing:

Hooray, finally the category of schemes is used in Sage! Question: Are there morphisms of schemes, yet? I am first reviewing #12875 and will then also look at the ticket here.

Apparently yes :-)

sage: sage: k = GF(11)
sage: E = EllipticCurve(k,[1,1])
sage: Q = E(6,5)
sage: phi = E.isogeny(Q)
sage: phi.parent()
Set of Morphisms from Abelian group of points on Elliptic Curve defined by y^2 = x^3 + x + 1 over Finite Field of size 11 to Abelian group of points on Elliptic Curve defined by y^2 = x^3 + 7*x + 8 over Finite Field of size 11 in Category of hom sets in Category of Schemes
sage: phi.parent().homset_category()
Category of hom sets in Category of Schemes

(which by the way should really be Category of Schemes; see #12880)

[SimonKing]

As you point out in a comment, due to the custom __getattr__ method, subclasses of LazyField can not be extension classes (because Parent.__getattr__ is only needed when the class of the parent can not be turned into a subclass of the category's parent_class).

I am sure that you did try something like getattr(super(self,LazyField),name). Did that not work? Why?

By consequence, you (have to) turn cdef class ComplexLazyField_class(LazyField) into class ComplexLazyField_class(LazyField). Did you investigate potential speed penalties?

In the initialisation of LocalGeneric, which inherits from CommutativeRing, you still call Parent.__init__ (with category support added), but not CommutativeRing.__init__, which would automatically grant category support. Why?

[SimonKing]

Replying to SimonKing:

I am sure that you did try something like getattr(super(self,LazyField),name). Did that not work? Why?

I tested (it should be super(LazyField,self)), and indeed it does not work. But still, one could add the stuff from the custom Parent.__getattr__ into the custom LazyField.__getattr__:

sage: cython("""         
....: from sage.structure.parent cimport Parent
....: from sage.structure.parent import getattr_from_other_class
....: cdef class MyParent(Parent):
....:     def __getattr__(self, name):
....:         print "here is the custom getattr with", name
....:         return getattr_from_other_class(self, self.category().parent_class, name)
....: """)
sage: P = MyParent(category=CommutativeAdditiveSemigroups())
here is the custom getattr with _element_constructor_
here is the custom getattr with Element
here is the custom getattr with element_class
sage: P.addition_table
here is the custom getattr with addition_table
here is the custom getattr with __custom_name
here is the custom getattr with _repr_
<bound method CommutativeAdditiveSemigroups.parent_class.addition_table of <type '_mnt_local_king__sage_temp_mpc622_12258_tmp_4_spyx_0.MyParent'>>

There is also some more stuff in Parent.__getattr__, that was written for cached methods.

The question is whether the code duplication would be worth the effort.

[SimonKing]

But it is really strange:

sage: MyParent.__getattr__  
<method '__getattr__' of '_mnt_local_king__sage_temp_mpc622_12258_tmp_4_spyx_0.MyParent' objects>
sage: Parent.__getattr__  
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)

/mnt/local/king/SAGE/experiment/notebook/sage-5.1.notebook/devel/sage-main/<ipython console> in <module>()

AttributeError: type object 'sage.structure.parent.Parent' has no attribute '__getattr__'

So, why is Parent.__getattr__ seemingly unavailable, although it is frequently used?

[nthiery]

Thanks for reproducing here my unsuccessful attempts :-)

Now is it worth the trouble? It's about the parent, not the elements. In the similar situation for QQ we decided for QQ not to be an extension type. It would be surprising if there would be methods on RLF that would be more critical than on QQ, wouldn't it?

Cheers,

Nicolas

[SimonKing]

Replying to nthiery:

Thanks for reproducing here my unsuccessful attempts :-)

You're welcome; but still I'd like to understand why one can see __getattr__ of a custom cdef class that is derived from Parent, but can not see __getattr__ of Parent.

[SimonKing]

There only remains one question: Why is Parent.__init__ and not CommutativeRing.__init__ called in LocalGeneric? Well, I'll test it, and will submit a reviewer patch if it works. With your patch, all doctests pass...

[SimonKing]

I see. Keywords such as element_constructor aren't accepted by CommutativeRing.__init__. So, no reviewer patch.

I accept your argument about RLF not being of extension type. Since the doctests pass and the patch looks fine, I give it a positive review.

However, I'd like to understand how Parent differs from other classes with a custom __getattr__.

[nthiery]

Replying to SimonKing:

I accept your argument about RLF not being of extension type. Since the doctests pass and the patch looks fine, I give it a positive review.

Thanks for the quick review!

However, I'd like to understand how Parent differs from other classes with a custom __getattr__.

I guess it's a question of extension types versus non extension types.

[SimonKing]

Replying to nthiery:

I guess it's a question of extension types versus non extension types.

No, it isn't.

sage: cython("""                  
....: cdef class MyParent(object):               
....:     def __getattr__(self, str name):
....:         raise AttributeError,name
....: """)
sage: MyParent.__getattr__
<method '__getattr__' of '_mnt_local_king__sage_temp_mpc622_20365_tmp_0_spyx_0.MyParent' objects>

At least that is what I find with sage-5.1.notebook. I do get an error in an old version of Sage that still uses the old Cython spkg.

[nthiery]

Replying to SimonKing:

Replying to nthiery:

I guess it's a question of extension types versus non extension types.

No, it isn't.

Ouch, that's weird ...