On Sep 29, 2012, at 2:49 AM, Joachim Durchholz <[email protected]> wrote:
> Am 28.09.2012 20:42, schrieb Aaron Meurer: >> I agree that C is probably not necessary, and really is not necessary >> to be included in "from sympy import *". So I'm +1 to remove it, >> unless we determine that it really is needed. Should we deprecate it >> first, or just remove it? > > +1 to deprecate, -1 to remove. > > Removal runs the risk of enraging people who use C and can't quickly change > their code. > > Deprecation would be enough for inside SymPy: the warnings happen in the call > site, which is what's getting changed anyway. > >> S on the other hand is quite useful. Because the members are >> singletonized, you can use "is" comparison (much faster than == >> comparison). > > That's generally true for each singleton. > > I'd suggest moving the singletons into the classes where they're created. I'm not sure if I understand you. The classes are the singletons. "sympify(0) is S.Zero is Zero" is True. > > > But this only works if you have the element itself, so >> for example, if you want to compare against 0, you have to first >> sympify 0. "a is S.Zero" is the cleanest way to do this. I'm also >> rather fond of the tab-completeable shortcut for 1/2 by S.Half in >> interactive use. > > Hm... Zero could be a class. > This is Python, things can be class, function, and dictionary all at once. I definitely don't understand what you're saying here. > >> Also, unlike C, S only eats up those objects that specifically set it >> as their metaclass. So the name clash issue that Ronan mentioned does >> not apply. I also seriously doubt any external code uses S to create >> its own singletons, though something like that would be perfectly >> acceptable and supported, so long as the names don't clash with >> existing names. > > They may clash with names created by other people who're using SymPy, so > freely combining code written by others isn't possible anymore. > Also, they may clash with names that future versions of SymPy place in S. Well, it will be supported modulo any name clashes. If you're worried about it, you can choose a name that you know will never clash. Aaron Meurer > > For this reason, adding stuff to S by anybody other than the SymPy team would > actually be a bad idea IMNSHO. > > Just my thoughts. > Regards, > Jo > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
