#17958: implement declare_var, deprecate (None)var
-----------------------------+------------------------
Reporter: rws | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-6.6
Component: symbolics | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: | Stopgaps:
-----------------------------+------------------------
Comment (by nbruin):
Replying to [comment:16 mmezzarobba]:
> I don't care much about "pythonicity", but what Volker suggests would be
consistent with the rest of Sage. And since this is all for interactive
use anyway, I don't see the problem with using the preparser, nor with
writing `_.<x> = SR()`.
>
> From a pedagogical point of view, it might actually be a good thing to
make it clearer that `var()` (or, to be precise, `symbol()`) is more or
less the same as `gen()`, only for `SR`.
It is ''not'' consistent with the rest of sage and hard to implement,
since presently it amounts to
{{{_ = SR(names=('x',)); (x,) = _._first_ngens(1)}}}
Normally, calling a constructor with different names gives different
results:
{{{
sage: PolynomialRing(QQ,names=('x',)) == PolynomialRing(QQ,names=('y',))
False
}}}
and we would need to hack `SR._first_ngens` to remember the last set of
generators that got returned.
The scenario really doesn't fit in the current meaning of `_.<..>=...`,
neither in implementation nor in semantics.
--
Ticket URL: <http://trac.sagemath.org/ticket/17958#comment:18>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
