On Saturday, 16 April 2022 at 05:37:16 UTC-7 list...@gmail.com wrote:

>
> Thanks Samuel and Emmanuel.
>
> Follow up question:  Why does
> var('lambda',n=1)
> fail?
>

Because the code in question tests the string actually passed in for 
whether it's a valid python identifier.

Probably this is because the "n" optional argument was only added later. 
However, there's been quite a discussion on what the appropriate binding 
behaviour should be. One option would be to bind the actual returned result 
(a tuple of the constructed symbols) to a name in the current namespace. 
i.e., the result of

x = SR.var('x',n=3) 

For that behaviour, the passed-in name would have to be a valid identifier. 
So to future-proof sage, perhaps it's better to have this stricter check.

You can create symbols without the check: SR.symbol('lambda') works just 
fine. To create the symbols you'd like, you can do:

L = (SR.symbol("lambda{}".format(i)) for i in range(3))

binding them to corresponding symbols would require a little more work . 
It's basically

for c in L:
    globals()[str(c)] = c

which works when typed in as-is, but requires some more trickery if it is 
wrapped in a function in some module, due to the semantics of the actual 
"globals()" call in python.

[in general, for anything other than direct interactive use, you should 
probably not rely on binding injections]

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/99f5b3eb-5e57-4f3f-922c-4a907cea4ba2n%40googlegroups.com.

Reply via email to