On Tue, Jan 17, 2012 at 9:53 AM, Burcin Erocal <bur...@erocal.org> wrote:
> 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
I'm concerned because this would cause a backwards incompatible change
that will break existing code that is not in the Sage library, hence
confuse people in another way. For example, consider the following
common construction:
@interact
def f(n=range(10)):
var('y')
plot(sin(y*n), (y,0,10)).show()
We would have to have a deprecation warning first, and a 1-year
waiting period before an error is raised.
Alternatively, is there a way to make var inject into the local
namespace? (I think not, by the way, but who knows what crazy stuff
people can do with Cython.)
>> > 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.
I've taught hundreds of people Sage at all levels (high school through
professors) for years and never ran into people professing being
seriously confused by the var command. I'm not saying it doesn't
happen, but if I haven't hit it at all with this many students, then
it can't be that bad of an issue for people learning Sage.
Nils example is interesting though, since it suggests using SR.var
instead of var in preparsing callable symbolic function creation.
E.g., instead of
sage: preparse('f(x) = 10*x')
'__tmp__=var("x"); f = symbolic_expression(Integer(10)*x).function(x)'
do
sage: preparse('f(x) = 10*x')
'__tmp__=SR.var("x"); f = symbolic_expression(Integer(10)*x).function(x)'
-- William
--
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
