#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 tmonteil):
Replying to [comment:11 vbraun]:
> `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.
Actually `SR.var` is a wrapper over `SR.symbol` that splits commas and
spaces to create tuples of symbols.
> How about something like `R.<x> = SR()` to get symbolic generators?
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.
Replying to [comment:13 mmezzarobba]:
> Definitely not `Symbol()`. As for `symbol()`, it could have been a
better name choice than `var()`, but I doubt switching to it now is a good
idea. The benefits are not that significant, and since `var()` is
proabably one of the most widely used functions outside the sage tree
itself (in particular, in random code snippets), the compatibility break
would be a pain for many of people (the recent deprecation of
`pol.coeffs()` already was pretty bad from this point of view).
The benefits are very significant for newcomers and anyone that interacts
with newcomers, i personally spent a huge amount of time to deal with that
issue (on ask.sagemath.org (see my previous link for a small sample) but
also during tutorials).
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. This is why we have a deprecation policy. For such a
function, we could make the deprecation message more verbose and
pedagogical than usual.
--
Ticket URL: <http://trac.sagemath.org/ticket/17958#comment:14>
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.
