implement declare_var, deprecate (None)var

[rwst]

Functions returning a value should not have side effects, var does. In #17447, comment 23 Nils Bruin proposed to separate both usages of var by introducing declare_var: this should behave exactly like var without return value, and var should not put the var handle in the globals list but should act like SR.var. If we want the following behaviour:

1. declare_var('x') == var('x') as before but returning None
2. var('x') prints deprecation message, returns variable as before; error after deprecation period
3. y = var('x') as before (but without globals), NO deprecation message
   we certainly need the preparser to recognize 2/3, and to replace (2) with declare_var('x'); deprecation(...); x and (3) with y = SR.var('x'). Secondly, there is a different docstring needed with var when compared with declare_var.

This and the same with functions is the most annoying problem for people doing calculus in Sage.

• http://ask.sagemath.org/question/8145/difference-between-varx-and-xvarx/

CC: @nbruin @kcrisman

Component: symbolics

Issue created by migration from https://trac.sagemath.org/ticket/17958

[rwst]

Description changed:

--- 
+++ 
@@ -1,17 +1,12 @@
-Functions returning a value should not have side effects, `var` does. In #17447, comment 23 Nils Bruin proposed to separate both usages of `var` by introducing `declare_var`: this should behave exactly like `var` without return value, i.e.
-
-```
-sage: var('y')
-y
-sage: declare_var('y')
-y
-sage: y = declare_var('y')
-sage: y
-sage: type(y)
-<type 'NoneType'>
-```
-Later, after all books are changed, `var` without return value should be phased out.
+Functions returning a value should not have side effects, `var` does. In #17447, comment 23 Nils Bruin proposed to separate both usages of `var` by introducing `declare_var`: this should behave exactly like `var` without return value, and `var` should not put the var handle in the `globals` list but should act like `SR.var`. If we want the following behaviour:
+1. `declare_var('x')` == `var('x')` as before but returning `None`
+2. `var('x')` prints deprecation message, returns variable as before; error after deprecation period
+3. `y = var('x')` as before (but without globals), NO deprecation message
+we certainly need the preparser to recognize 2/3, and to replace (2) with `declare_var('x'); deprecation(...); x` and (3) with `y = SR.var('x')`. Secondly, there is a different docstring needed with `var` when compared with `declare_var`.
 
 This and the same with functions is the most annoying problem for people doing calculus in Sage.
 
 * http://ask.sagemath.org/question/8145/difference-between-varx-and-xvarx/
+
+Also #6559 deprecated the `ns` keyword 5 years ago, let's remove it from `var()`.
+

[mezzarobba]

comment:3

Does sage really need a version of var() that touches the global namespace? Other similar functions like polygen() and *.gen() don't do it, except for a handful of constructors after inject_on()—which I doubt anyone uses. And y = var('y') is clearer and shorter than declare_var('y'), though it would be nice if y = var() (or perhaps <y> = var()?) was preparsed to y = SR.var('y').

[rwst]

comment:4

Not really need but:

sage -t src/sage/symbolic/expression.pyx  # 424 doctests failed
sage -t src/sage/symbolic/assumptions.py  # 51 doctests failed
sage -t src/sage/symbolic/callable.py  # 48 doctests failed
sage -t src/sage/calculus/riemann.pyx  # 126 doctests failed
sage -t src/sage/calculus/calculus.py  # 81 doctests failed
sage -t src/sage/calculus/tests.py  # 29 doctests failed
sage -t src/sage/calculus/wester.py  # 29 doctests failed
sage -t src/doc/en/prep/Advanced-2DPlotting.rst  # 24 doctests failed
sage -t src/doc/en/prep/Quickstarts/Multivariable-Calculus.rst  # 38 doctests failed
sage -t src/doc/de/thematische_anleitungen/sage_gymnasium.rst  # 31 doctests failed
sage -t src/sage/functions/piecewise.py  # 25 doctests failed

That's those over 20 in symbolic,calculus,doc,functions.

EDIT: grep for 'sage: var(' shows 338 hits in 67 files...

[rwst]

comment:5

I should have looked sooner: the catch is, I removed the globals injection in calculus/var.pyx:var() and the variables get still injected. And indeed the same with SR.var(), so that has side effects too and is no cure for the matter.

EDIT: Noo, that's wrong, it's the expression on the lhs that gets injected!

I still have to find a case where injection of the variable itself matters.

[mezzarobba]

comment:6

I think I don't understand what you mean:

sage: SR.var('xyz')
xyz
sage: xyz
...
NameError: name 'xyz' is not defined

[rwst]

comment:7

I still have to find a case where injection of the variable itself matters.

Sorry, I should say... where injection via globals in the var function makes a difference versus ex = SR.var(...), where presumably globals is filled by iPython with the ex.

[videlec]

comment:8

The name var by itself makes a lot of confusion. There are Python variables which are a very different concept. What about calling it symbol or Symbol as it is done in sympy?

Vincent

[egourgoulhon]

comment:9

Replying to @videlec:

The name var by itself makes a lot of confusion. There are Python variables which are a very different concept. What about calling it symbol or Symbol as it is done in sympy?

+1

Eric.

[sagetrac-tmonteil]

comment:10

Replying to @egourgoulhon:

Replying to @videlec:

The name var by itself makes a lot of confusion. There are Python variables which are a very different concept. What about calling it symbol or Symbol as it is done in sympy?

+1

Eric.

+1 as well, the name "variable" causes a lot of troubles to newcommers that use var() to declare Python names, see for example this list of ask questions. Instead of a generic "variable", we should use "symbol" for SR, "name" (for Python), "indeterminate" for polynomials. This will help learning Sage a lot.

By the way, note the difference between

sage: SR.var('x,y')
(x, y)

and

sage: SR.symbol('x,y')
x,y
sage: SR.symbol('x y')
x y

So perhaps should we also make a difference between Symbol and Symbols ?

[vbraun]

comment:11

SR.var does exactly what the declare_var does without the drawbacks of an additional global, so as it stands I'm against the ticket description.

SR.symbol and SR.var should probably be aliases but aren't. I wasn't even aware of SR.symbol, which is why I only fixed the comma parsing in SR.var in #7496.

How about something like R.<x> = SR() to get symbolic generators?