Hi! On 2013-02-11, Nils Bruin <[email protected]> wrote: > The process of transplanting a discussion from a trac ticket (#14084 > in this case) to sage-devel is a bit painful.
Sorry that I posted to trac after you posted here. >> Also note that changing the category of the ring has indirect >> advantages: There may be more parent and element methods become >> available when passing to a sub-category. > > The problem is that if such advantages happen unpredictably then when > they don't happen they are just as big a disadvantage. In the old ways, there were rings R so that R.is_field() would return True, but R.category() returned Rings() (or CommutativeRings(), if one was lucky). Therefore, someone made a special case for containment in the category of fields (it wasn't I), relying not only on the category given to R, but also to the output of the function is_Field. Hence, it was possible to have R in Fields() but R not in IntegralDomains(), R.category() just being Rings(). That is perhaps more predictably, but I think also more confusing. Note that the class of a parent R changes when the parent's category is initialised---unless it is an extension class. This is simply how the category framework works. And if you pass to a sub-category, then you pass to a sub-class. Hence, you may have additional methods, and you may overrided methods by more specialised code, but you will not lose functionality. > If you're > experimenting in an environment where, unbeknownst to you, the ring > you're creating is in fact one that was created before, where it was > queried about its fieldness, you are going to be very disappointed and > confused if your example-now-turned-library-code suddenly doesn't work > anymore because in the new environment there doesn't happen to be a > ready-made ring instance available. > ... > I think we really shouldn't be changing types of > objects already in play. Granted, the rings in question should just be initialised in the "best" category right away, if possible. Then, there would be no reason to change types after initialisation. But in some cases the performance loss is considerable. If you just use MatrixSpace as a container, then initialising it as a vector space or an algebra would be a waste of time. I think in these cases it is in order to postpone the initialisation of the category. > By the way, is it really so bad that MRO can be affected by category > change? Are we changing types as well? Yes. This is how the category framework works. And this is why under *normal* circumstances the category is only initialised during creation of the instance. > I was hoping this problem was > localized because it only affects the value of the category field, Nope. Actually, the change of MRO comes in two flavours. If you initialise (or refine) the category, then the class and thus the mro changes (if possible), and so Python can look up additional methods really fast. If you just change the cdef self._category attribute, or if changing the class is impossible (Cython), then a __getattr__ method will find the addional methods without changing the mro - and that's slow. > I don't think python was designed with that in mind. Then look at Python's abc (abstract base classes) module. At some point, I played with the idea to use the abc module for making the category framework yet more flexible - but I guess some people would say that changing subclass hooks on the fly is just yet more scary... > If the type of a parent remains the same throughout, then at > least method inheritance isn't affected. It is affected. There actually is an example in my thematic tutorial on coercion and categories (for elements, but it is the same for parents). Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-devel" 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-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
