On Jun 5, 2008, at 12:37 PM, Bill Page wrote: > On Thu, Jun 5, 2008 at 1:18 PM, William Stein wrote: >> ... >> On Thu, Jun 5, 2008 at 12:23 PM, Gonzalo Tornaria wrote: >> ... >>> sage: def classinteger(m): >>> ... class A: >>> ... def __init__(self, n): >>> ... self.__n = n % m >>> ... def __repr__(self): >>> ... return "%d mod %d" % (self.__n, m) >>> ... A.__name__ = "classintegers mod %d" % m >>> ... return A >>> sage: classinteger(5)(3) >> ... >> OK, I have to come clean and admit that already actually knew >> all about metaclasses, but considered using them this way so >> unnatural and ugly that I would not recommend it. >> > > Do you still consider the example code like that given above by > Gonzalo "unnatural and ugly"? It seems like pretty standard Python to > me. There of course various ways of packaging the metaclass machinery > to provide an even cleaner user interface. > > 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.
Parents are much, much more than types, and I see little to gain by trying to unify the two. To me, "Python class" and "object in some category" are very different concepts. There are, however, many drawbacks. First, there is far from a one- two-one correspondence between types an parents. Some parents have elements of varying type, and some types are used for a variety of parents. Though metaclasses can be used to mitigate this somewhat, I think it would add much more complexity than it would remove. Also, the __call__ method often does much more than just construct a new object. It would also introduce enormous performance overhead--the cost of calling classinteger above increases linearly with the number of methods the class has. Perhaps this could be limited by pre-creating the methods and adding them to the dict all at once, but but this would be even more unnatural. More importantly, this would mean that cdef'd (Cython) elements/parents are out. (Well, one could generate a cython file at run time, compile it, load the .so and then use that "dynamically generated type," but that would be so insanely slow). Is this a deficiency of cdef'd types? Yes. But this is what makes them so fast--members and methods can be statically resolved at compile time. - 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 -~----------~----~----~----~------~----~------~--~---
