#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 mmezzarobba):
Replying to [comment:14 tmonteil]:
> This is non-pythonic, requires additional preparsing, needs to create
the name `R` while the ring `SR` is already here, and will add even more
confusion to newcomers that hardly understand the difference between a
symbolic expression like `x^2+1` and a well defined polynomial over a well
defined ring.
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`.
> Sage is full of inconsistencies, refusing to clean them because they are
used increases the entry cost and will eventually lead to an obscure
language where each function/method has its own semantics. This is not
long-term viable.
I tend to agree in general, but I am not convinced in this particular
case. Having a longer function name is inconvenient, and I find `symbol()`
only marginally clearer (if at all) than `SR.var()`. (I'm fine with either
removing `var()` entirely or making it equivalent to `SR.var()`, however.)
> This is why we have a deprecation policy.
The deprecation policy is a joke... Except perhaps for a few
`_`-functions, just about anything in sage can be considered public, but
only few changes are considered worth a deprecation.
> For such a function, we could make the deprecation message more verbose
and pedagogical than usual.
Yes, but please keep in mind that it will pop up everywhere for a long
time.
--
Ticket URL: <http://trac.sagemath.org/ticket/17958#comment:16>
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.
