Thanks for the explanation, Nils (even if I am not sure to have understood
everything).
Guillermo
On Sat, 16 Apr 2022 at 22:56, Nils Bruin <nbr...@sfu.ca> wrote:
> 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/CANnG18_GP8Y0Ftx-Gt0RFM4KUd3%2B%3Dueh%3DQTBQ_jGsrAJoPKwpg%40mail.gmail.com.
