On Sep 2, 5:28 am, William Stein <wst...@gmail.com> wrote: > On Wed, Sep 1, 2010 at 6:08 PM, Jason Grout <jason-s...@creativetrax.com> > wrote: > > On 9/1/10 10:32 AM, Bill Hart wrote: > > >> Tim, > > >> all screwing around aside for a moment. I broadly agree with your > >> sentiments. However, there are also some issues with what you are > >> suggesting. And I mean to make these observations in all seriousness. > > > I'm reading this thread with great interest. Though I don't have strong > > feelings one way or the other at this time, your post made a lot of sense to > > me. Thanks for the post. > > > Jason > > I've written a blog post that is relevant to this thread: > > http://389a.blogspot.com/2010/09/purple-sage.html >
"PSAGE could in the long run lead to a more modular approach to Sage itself. For example, the PSAGE library will be a Python library like any other, and it should be possible to just install it into an existing Sage as an optional package. " But could it become incompatible with other Sage stuff? For instance, probably even in existing spkgs there could be competing definitions of this or that thing... or maybe not? It would be helpful to have it be an optional package from the beginning, so that if we ever (!) got automated testing, one could just take a fresh build, install psage, and then run doctests. If what I'm saying doesn't make sense (maybe because of namespaces not conflicting?), sorry for the noise. It would just be nice to make sure that some of the prophecies occasionally made on this list about Sage's death didn't happen prematurely because a lot of active developers realized psage was more useful to them without it being totally compatible from the start :) - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
