On Sep 20, 10:20 am, jireva <jose.i.ro...@gmail.com> wrote:
> Hello everyone,
>
> The following creates three variables ``a``, ``b``, and ``c``::
>
> sage: var('a, b, c')
> (a, b, c)
>
> I would expect this to do the same thing::
>
> sage: var(('a', 'b', 'c'))
> (('a', 'b', 'c'))
>
> It doesn't, but that's not too big a problem...
It's actually just as big a problem as the third example you give:
sage: l=var(('a','b','c'))
sage: l
(('a', 'b', 'c'))
sage: type(l)
<type 'tuple'>
sage: l[0]
('a'
sage: l[1]
'b'
sage: l[2]
'c')
sage: [type(c) for c in l]
[<type 'sage.symbolic.expression.Expression'>, <type
'sage.symbolic.expression.Expression'>, <type
'sage.symbolic.expression.Expression'>]
What's happening is that "var" is simply taking "str" of its argument
and working with that.
http://trac.sagemath.org/sage_trac/ticket/7496
should partly deal with the nasty bits of this problem.
The assumption that var(("a","b","c")) or var (["a","b","c"]) or
var("a","b","c") should be equivalent to
var("a");var("b");var("c")
is not corroborated by the documentation, by the way. It specifies var
takes a single argument, s (a string). Therefore, its behaviour of
trying to make sense of its argument by applying "str" to it is not
entirely unreasonable, but it should be a little more careful throwing
errors on bad input.
One way of reading your proposal is to change the behaviour of
var(...) so that var(<iterable>) produces
tuple(var(v) for v in <iterable>).
One problem with this that strings *are* iterables, so this proposal
would be inconsistent with the current behaviour:
sage: tuple(var(v) for v in "a_long_variable")
(a, _, l, o, n, g, _, v, a, r, i, a, b, l, e)
Probably you'd have to specify the new behaviour for iterables
*except* strings. However, once input specs need exceptions, you're
probably doing something wrong,. Therefore, it's not so clear to me
that
sage: var(v for v in ('a', 'b', 'c'))
should do what you'd hope it does. Perhaps it should just throw an
error and only accept input that is obviously meant as a string.
[note, by the way that top-level "var" has the nasty side-effect of
inserting bindings in globals(). As soon as you're using "var" in
programmatic contexts it's probably safer to stick with SR.var(...) ]
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
