On Jun 5, 2008, at 3:39 PM, Carl Witty wrote: > On Jun 5, 12:37 pm, "Bill Page" <[EMAIL PROTECTED]> wrote: >> The point I am making is that Python already has everything you need >> to implement the concept of the "parent" of an element as a type, >> i.e. >> directly as an instance of the class that creates it. This could >> result in considerable simplification compared to the current >> situation. Right now a Sage user has to deal with three separate >> type-related concepts: type (Python class), parent (an object in some >> category) and category. Metaclasses are a good match for Categories. >> Thus you can have everything in one package and remain closer to >> conventional Python programming in spirit. > > OK, I'm convinced that unifying parents and types is elegant and works > very well in Aldor, and that it's possible in Python. However, I > don't think it's a good idea for Sage, because of pragmatic > limitations due to Python/Cython. These points were all made by other > people in this thread, but I'm combining them into one convenient list > here for debating purposes. > > 1. Creating classes at run-time in Python is slow and memory-hungry; > the more methods you add to the class, the slower and more memory- > hungry it gets. > > 2. Creating classes at run-time in Cython is impossible. If Cython > was extended to support creating classes at run-time (which it may be, > at some point, since there are Cython developers who want it to > compile the entire Python language) there would need to be significant > language extensions (and corresponding compiler extensions) to let > these run-time be classes be as fast as the former compile-time > classes. > > 3. While it is possible in Python to add methods to types, these > methods are inherited by values of that type. Currently, we have > methods on parents that are not inherited by methods on the values; we > don't want to lose that. > > Here are some other points that were made, but seem to me less > important than the above: > > 4. Currently, if P is a parent and T is a type, P(...) and T(...) both > have meanings which are not the same. If we merged parents and types, > we would have to leave the function-call syntax for constructors, and > come up with a new syntax for conversion (coercion). This would be > annoying and non-backward-compatible, but is not a fatal flaw. > > 5. People have mentioned that we have cases where values of the same > type can have different parents, like IntegerMod_int which is the > implementation for both GF(7) and Integers(7). This particular case > is not a problem at all... we could just have GF(7) inherit from > Integers(7). > > 6. People have mentioned that we have cases where values of different > types share the same parent, such as symbolic constants and symbolic > expressions both being in the symbolic ring. This may sometimes not > be a problem; for instance, parent(x)==SR could be replaced by > isinstance(x, SR), even though type(x)==SR would not work. > > In summary, I think we could unify parents and types with a large > amount of work and a significant performance loss; or with a very > large amount of work (including a lot of work on Cython) and a minor > performance loss. In either case, we would have a functionality loss > (the ability to put methods on parents that are not inherited by > values). > > I don't think it's worth it.
I think that sums it up well (though personally I think types and parents are distinct enough concepts that keeping them separate is a good idea anyways). On (2), creating classes at runtime will certainly be supported, that's how "normal" classes are done now, but creating cdef classes at runtime without invoking gcc (or some other sort of compiler) at runtime is perhaps not even possible. For (6) we do a lot of "parent(x) is SR", especially in the fast paths of the coercion model (due to caching, parents are usually unique, and if not we follow it up by the (relatively expensive) ==, so even with a very large amount of work, that would still slow things down. This thread got slightly off topic to the original question though: where should sqrt(2) belong? Z[sqrt(2)], SR, or somewhere else? - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
