> Wouldn't it be clearer if the error message read
>
> NameError: name 't' is not defined, try var('t') beforehand
>
> or something similar?
>
> Perhaps as Carl deprecates common anticipated behaviors he'd be open
> to having his patch adjust the permanent error messages (not just the
> deprecation warnings) to give advice on the correct syntax/usage when
> possible. I'm starting to see some of this in Ubuntu Linux and the
> error messages are giving hints that took me hours to discover on my
> own a couple years ago.
This is an excellent idea no matter what is happening with variables,
assuming that this particular error message is usually the right
response to this NameError. That's when I see it, but I assume there
are other times this NameError also appears. Otherwise this sounds
like a ticket to open.
> With a little python magic, we can work around this.
> sage: def f(x,y):
> ....: return x + x*y
> ....:
> sage: f.func_code.co_argcount
> 2
> sage: f.func_code.co_varnames
> ('x', 'y')
>
> We could write a wrapper that takes a python function, and returns
> another one that takes keyword arguments. Then the plotting code would
> use this wrapper as a preprocessor before doing anything with python
> functions.
Certainly it makes sense to make this *possible*! Sure - absolutely,
there should be options, consistency should be possible if we can do
it.
But it just seems weird to me to choose consistency as the overriding
factor, to the point of deprecating *unambiguous* functionality that
already exists and does not cause problems (e.g. plot(x^2,0,1) or
integrate(x^2,0,1) ).
- kcrisman
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
