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. Carl --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
