# HG changeset patch
# User Nicolas M. Thiery
# Date 1335792780 7200
# Node ID 8857f7453fc31f124b44c756f5b344063da16c38
# Parent 8cb952b620272c390b09116a3a0880388a2d1547
[mq]: trac_12876_categoryfix_abstract_classntrel11521reviewnt.patch
diff git a/sage/categories/hecke_modules.py b/sage/categories/hecke_modules.py
 a/sage/categories/hecke_modules.py
+++ b/sage/categories/hecke_modules.py
@@ 116,7 +116,7 @@ class HeckeModules(Category_module):
Fixing :meth:`_test_zero` (``__call__`` should accept a
function as input) and :meth:`_test_elements` (modular
form morphisms elements should inherit from categories) is
 :trac:`???`.
+ :trac:`12879`.
TESTS::
diff git a/sage/categories/rings.py b/sage/categories/rings.py
 a/sage/categories/rings.py
+++ b/sage/categories/rings.py
@@ 561,63 +561,4 @@ class Rings(Category_singleton):
class HomCategory(HomCategory):
 def extra_super_categories(self):
 """
 EXAMPLES::

 sage: Rings().hom_category().extra_super_categories()
 [Category of sets]
 """
 from sage.categories.sets_cat import Sets
 return [Sets()]

# def get_Parent(self, X, Y):
# """
# Given two objects X and Y in this category, returns the parent
# class to be used for the collection of the morphisms of this
# category between X and Y.

# Returns self.ParentMethods by default.

# Rationale: some categories, like Rings or Schemes, currently
# use different classes for their homset, depending on some
# specific properties of X or Y which do not fit in the category
# hierarchy. For example, if X is a quotient field, morphisms
# can be defined by the image of the generators, even if Y
# itself is not a quotient field.

# Design question: should this really concern the parent for the
# homset, or just the possible classes for the elements?
# """
# category = self.base_category
# assert(X in category and Y in category)
# # return self.hom_category()(X, Y)?
# #print self.hom_category(), X, Y, self.hom_category().parent_class, self.hom_category().parent_class.mro()
# return self.ParentMethods

 class ParentMethods:
 # Design issue: when X is a quotient field, we can build
 # morphisms from X to Y by specifying the images of the
 # generators. This is not something about the category,
 # because Y need not be a quotient field.

 # Currently, and to minimize the changes, this is done by
 # delegating the job to RingHomset. This is not very robust:
 # for example, only one category can do this hack.

 # This should be cleaned up upon the next homset overhaul

 def __new__bx(cls, X, Y, category):
 """
 """
 from sage.rings.homset import RingHomset
 return RingHomset(X, Y, category = category)

 def __getnewargs__(self):
 """
 Note: without this method, :meth:`.__new__` gets called with no
 argument upon unpickling. Maybe it would be preferable to
 have :meth:`.__new__` accept to be called without arguments.

 """
 return (self.domain(), self.codomain(), self.category())
+ pass
diff git a/sage/schemes/elliptic_curves/ell_curve_isogeny.py b/sage/schemes/elliptic_curves/ell_curve_isogeny.py
 a/sage/schemes/elliptic_curves/ell_curve_isogeny.py
+++ b/sage/schemes/elliptic_curves/ell_curve_isogeny.py
@@ 3345,11 +3345,11 @@ class EllipticCurveIsogeny(Morphism):
sage: phi._composition_(phi, phi.parent())
Traceback (most recent call last):
...
 NotImplementedError
+ NotImplementedError
The following should test that :meth:`_composition_` is called
upon a product. However phi is currently improperly
 constructed (see :trac:``), which triggers an assertion
+ constructed (see :trac:`12880`), which triggers an assertion
failure before the actual call ::
sage: phi*phi