On Tue, 17 Jan 2012 09:02:11 -0800 (PST) Nils Bruin <nbr...@sfu.ca> wrote:
> On Jan 17, 2:54 am, Keshav Kini <keshav.k...@gmail.com> wrote: > [...] > > How does it make anything easier > > or clearer or better for the interactive user that var() injects > > things into global scope? We found ourselves trying in vain to > > explain this to students several times when teaching our Sage-based > > undergraduate course last fall. (CCing to sage-devel, assuming I > > did this right...) > > The preprocessor allows even finer jewels: > > sage: y=1 > sage: def one(): > ....: _(y)=1 > ....: return 1 > ....: > sage: one() > 1 > sage: y > y > > If this is biting people so badly, perhaps "var" should inspect its > call frames via "frame=inspect.currentframe()" and dig down a bit with > "frame.f_back" to see if it's at the sage top-level. If it's not, it > could throw an error instructing people to use a non-globals- > clobbering version of var (e.g., SR.var) instead. Since this routine > goes digging in globals anyway, I think it's quite reasonable if it > also does some stack frame exploring. Good idea! One possible drawback is that most users who call var() from a function definition will not understand what we mean by "top level." Any suggestions for an informative error message? Are we also going to prevent people from defining callable expressions using the f(x) = x+1 syntax within functions? > Using a globals-clobbering "var" at anything but top-level is almost > certainly undesirable, so perhaps it's better to forbid it. +1 Cheers, Burcin -- 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
