To summarize the previous answers (and nitpick a bit) : automatic_names - may come handy ; - shouldn't be mandatory - shouldn't be the default - should print a warning when fired. I also liked the idea of introducing a new magic controlling that feature. However, I have a couple of remarks :
- Some functions (mostly inherited from Maxima) *do* already create new symbolic variables, but do not inject them in the relevant namespace. In *this* case (and this case only), I'd like to have this injection done by default, but controllable via an option. *Prima facie,* our targets are solve and desolve + their friends. But I forget some other ones almost surely... Hints ? - The idea of a line magic (i. e. enabling automatic_variables for the next instruction or block) should be paired with a corresponding cell magic. - Another pair of magics could control the *silent* automatic declaration of new symbolic variables. The first case might be covered by patching the current implementation of the target functions ; the control of the injection of the new variables (in fact, symbolic constants) in the relevant name space could be controlled by yet another (pair of) magic(s). Hence the possible design of the new magics : - %(%)auto_constants : control whether Maxima-generated constants are injected in the relevant namespace. Default : True. - %(%)auto_variables : control whether unknown names trigger the creation of symbolic variables thus named. Triggers a message. Defaulf : False. - %(%)silent_auto_variables : control if the message signaling the creation of an automatic variable should vbe supressed. Defaulf : False. Critics ? Suggestions ? Lazzi ? This just leaves the $10000 question : who implements this ? ;-). -- Emmanuel Charpentier Le lundi 19 mars 2018 14:06:15 UTC+1, Nicolas M. Thiéry a écrit : > > On Thu, Mar 15, 2018 at 08:49:02AM -0700, William Stein wrote: > > On Thu, Mar 15, 2018 at 7:43 AM, Emmanuel Charpentier > > <emanuel.c...@gmail.com <javascript:>> wrote: > > > [...] However, most CASes now available do away without this mandatory > declaration. > > > > And hence Sage should have automatic_names as a non-default *option*. > > Yeah; it's all a balance between simplicity vs risk of confusion. From > using, teaching, and witnessing people teach SageMath, there are some > contexts where you (or more likely your teacher!) know what you are > doing, there is no risk of confusion, and simplicity primes. Most of > the time we don't want it though. So +1 as well on automatic_names as > an option not set by default. Also +1 on the message when a variable > is created. > > Finally, I could suggest to write it as: > > %automatic_names > > to highlight that this is a magic command that alters the behavior of > the interpreter. > > Cheers, > Nicolas > -- > Nicolas M. Thiéry "Isil" <nth...@users.sf.net <javascript:>> > http://Nicolas.Thiery.name/ > -- 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.
