On Thu, Jun 5, 2008 at 6:39 PM, Carl Witty wrote: > > 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.
Thanks for summarizing the arguments against unifying parents and types in Sage. As I stated near the start of this thread, it was not my intention to recommend that Sage actually take this approach. Sage is 3.0 and the current approach is established and working well for the end user. My regret however is that it seems to make new development in Sage more complicated, with a steeper learning curve for new developers than it really needs to be. On Thu, Jun 5, 2008 at 9:09 PM, Gonzalo Tornaria <[EMAIL PROTECTED]> wrote: > >> >> On Thu, Jun 5, 2008 at 1:18 PM, William Stein wrote: >> > 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. >> > >> > On 6/5/08, Bill Page <[EMAIL PROTECTED]> wrote: >> 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. > > I do think my code (as posted) is "unnatural and ugly". Just an > example, not even a class. I'd really love to figure out a proper > model of parent-element relationship using metaclasses, etc. > It seems to me that the parent-element relationship is already there. It is inherent in the Python concept of an instance of a class. In this model classes *are* parents. Instances are elements. Your example code presents a function that generates classes based on a parameter - a standard "class factory". As you say, what might be more interesting is a class that behaves like a category, i.e. whose instances themselves are classes. Python's type module is an example of such a metaclass. I think this is all very well and concisely described here: http://www.onlamp.com/pub/a/python/2003/04/17/metaclasses.html A Primer on Python Metaclass Programming by David Mertz > I tried very hard (several times) to find such a model, or at least > "a cleaner user interface", and I played with some interesting ideas > but cooked no cake. > > Maybe you have some cool ideas on how one can make this work > (and appealing to others). > Have you looked at the 'type' class? I think that is pretty cool. >> category) and category. Metaclasses are a good match for >> Categories. > > Also cool. I remember I was hit by the python version of a few of > the paradoxes in early days set theory. YMMV. > I don't think you should let apparent paradoxes in set theory worry you. OpenAxiom for example has a domain called Domain. Domain is an instance of Domain so we can write: x:Domain:=Domain and the world does not end.. And would I really would like to get as much mileage as possible from native Python constructions. In the Axiom world we have a bit of a problem: Unlike Axiom itself, the new generation Axiom library compiler - Aldor - is not free (although just last year it finally became at least "semi-open"). In my opinion, to progress rapidly and as intended when Axiom was still a commercial product Axiom badly needs Aldor. The existing compiler in Axiom - SPAD - is significantly harder to use and to extend (although Gabriel Dos Reis has started to do some wonderful new things with it in the OpenAxiom fork of the original open source Axiom project.). I think this is one of the main reasons why Axiom has had a relatively difficult time attracting new uses and developers. Even Aldor however is already a rather "old" language. There has been a lot of progress in programming language design since the mid 1990's. Python is one result. It seems to me that Python has many of the attributes of the kind of language that the Axiom developers were trying to achieve. This is one of the primary reasons why I was interested in the Sage project in the first place. Sage is not Axiom, but it is (more or less) based on Magma and Magma has at least some of the features that I think make Axiom rather special as a computer algebra system. So like several other people before me, e.g. the developers of Sage and the developers of SymPy, I am now thinking quite seriously about how much of the Axiom design could actually be accommodated in Python. Implementing domains and categories as Python classes is an essential part of that strategy. Regards, Bill Page. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
