On Fri, Mar 16, 2018 at 6:13 PM, William Stein <wst...@gmail.com> wrote: > On Fri, Mar 16, 2018 at 9:47 AM, Nils Bruin <nbr...@sfu.ca> wrote: >> On Thursday, March 15, 2018 at 7:43:45 AM UTC-7, Emmanuel Charpentier wrote: >>> >>> Two chronic offenders are Maxima's solver and differential equation >>> solver(s), which routinely add new symbolic constants as required by their >>> inputs. In these cases, getting the names of these new variables and >>> properly declaring them for future use can become a pain in the ass. >>> >>> In these cases (and other possible automatic variable creation i do dot >>> have in mind currently), such auto_declare behaviour should be the >>> *default*. >>> >> These are separate issues. The option "automatic_names" inserts bindings to >> SR symbols when code that is interactively input references an unbound name >> (and would raise a NameError). That's orthogonal to SR symbols that get >> created without being bound to a "global" name. The latter creation may even >> happen when there's no interactive namespace present in the system, and >> certainly no obvious reference to one would be available. That means it's >> not even clear where to insert the binding. >> >> Implementing the feature in IPython is exactly the right place, because that >> DOES have a good notion of what the interactive namespace would be. I assume >> CoCalc behaves (largely) as IPython for API purposes. > > If you implement this in IPython, then I'll still have to implement it > again for CoCalc, > since CoCalc Sage worksheets don't use IPython. I don't really see > any way around this though. > This feature is not implemented by parsing the code, so it has to be > done by whatever eval's the > code. We could technically add via the preprocessor some ugly while > try/except around *all* > code before it is evaluated, but that would be horrendous.
I'm not really sure I understand the problem here, though maybe I'm being naïve. But ISTM the implementation of this is mostly the same regardless what the frontend is. The only difference is in how one hooks into the frontend to perform input preprocessing. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
