deprecate substitution via __call__ w/ unnamed arguments

[sagetrac-cwitty]

As discussed on sage-devel here: http://groups.google.com/group/sage-devel/browse_thread/thread/b1a03f8fc8ae8fcd/553773d7ba600ae7#553773d7ba600ae7

I added deprecation warnings to the four affected __call__ functions (two for symbolic values, one for equations, one for matrices), and fixed almost all the warnings in all the doctests other than the doctests specifically for those __call__ methods.

There's one set of warnings that I didn't figure out how to fix (in piecewise.py), so I just added the warning to the expected output for now.

CC: @jasongrout

Component: calculus

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

[sagetrac-mabshoff]

comment:1

Two trivial doctest failures:

sage -t -long devel/sage/doc/en/constructions/calculus.rst # 1 doctests failed
sage -t -long devel/sage/doc/fr/tutorial/tour_algebra.rst # 1 doctests failed

Cheers,

Michael

[sagetrac-cwitty]

comment:3

Attachment: deprecate-symbolic-unnamed-call.patch.gz

Oops, forgot to doctest the documentation. I've replaced my original patch with a new one that also fixes these two doctest failures.

[jasongrout]

comment:4

This is an (email) reminder to myself to review this to get it in.

[jasongrout]

comment:5

This ticket probably also affects #5093.

[burcin]

comment:6

Thanks for working on this Carl.

I only read the patch, didn't test it yet. Explicitly having to use .function() in two places bothers me:

• for each component of Piecewise
• in the call to generate_plot_points

Perhaps we should modify these to handle non function arguments more gracefully after this change.

I understand that this might require a new syntax to construct Piecewise objects. One option is to add a new parameter, which includes an ordered list of variables. E.g.,

    sage: Piecewise([[(0,1),x^2],[(1,2),5-x^2]] ,[x])

or

    sage: f = Piecewise([[(-1,1),1/2+x-x^3 + y]],[x,y])

Comments?

[jasongrout]

comment:7

The above comment for Piecewise would probably also apply to symbolic matrices and vectors, right? (well, at least, as soon as symbolic vectors are callable, anyway). I think that Burcin's proposal is okay, but doesn't extend very well to matrices and vectors, since I'd hate to mess up the standard matrix/vector constructors. I'm don't know a better way to extend this to matrices and vectors, though. Maybe we ought to just deprecate calling a symbolic matrix without keyword arguments, and just implement the callable symbolic vector with the same restrictions.