On Thursday, May 25, 2017 at 4:40:01 PM UTC-7, Nils Bruin wrote: > > incidentally, it would be nice if we could equiv local/bin/ipython with > the proper sage-python23 as well. Having a functional shell with an > interactive debugger is a much nicer way to debug "import sage.all". >
This is a design question for which we do not have an answer, or even any real suggestions. Right now, SAGE_PYTHON3=yes is purely for building Sage, not for running it, and maybe long-term it should get replaced with a configure option anyway. Python conventions say that "python" should always mean "Python 2", so if we want to follow those conventions, then local/bin/python should not be sage-python23. - Should we try to determine somehow whether Sage was built for Python 2 or Python 3, and have the script "sage" behave accordingly? (What if you've built without setting SAGE_PYTHON3 and then you rebuild with SAGE_PYTHON3=yes, without doing "make distclean" in between? With the current state of affairs, all sorts of things will break: this is a bad idea. But should you be able to do this?) - Should we instead have a separate script "sage3" which we run using "sage --some-command-line-option"? - Should we build everything for both versions of Python, and then let the user choose at run time? I'm sure there are plenty of other similar questions. Does anyone have opinions on any of them, either from the point of view of user preference or the point of view of implementation? -- John -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
