>> - Permitting only Basic instances in args causes much pain: Symbol, >> for instance, does not contain its name in its args. Every time that >> we want to have a named object we jump trough hoops. This breaks >> obj.func(*obj.args)==obj. There is no clear notion of atomic object in >> sympy: some of the tree traversal algorithms check for empty args, >> other for subclasses of Atom, etc. > > Well, Symbol does derive from Basic. Further, x.func(*x.args) != x, > where x is a Symbol, exactly because Symbol doesn't store its name in > Basic.args. Therefore, I fail to see how allowing or not allowing > FiniteSet to store arbitrary objects is related, sorry.
That is what I said. Symbol does not follow x.func(*x.args)==x exactly because it does not have the right to contain a string in its args. >> The only argument that I have seen in favor of demanding only Basic in >> args is for ease tree traversal. But if we set up sane rules and we >> stick to them this would be completely unnecessary. > > Well, yes, you're right. I can't think of any other argument. > However, this very tree traversal requirement is apparently > sufficiently important to condition the necessity that everything in > .args be Basic. I have made the suggestion to only allow Basic's in > FiniteSet having that in mind. > > In general, from what I understand, Basic should serve as the base > class for all those objects which represent mathematical entities. To > me, the majority of mathematical entities are inherently immutable and > therefore rather easy to implement as subclasses of Basic. I may be > grossly wrong, though. Basic should serve for a base class, yes, however search for "isinstance considered harmful". Forcing users to subclass Basic is a bad idea because it just adds cruft. If your object supports all the interfaces expected from Basic (mainly having args) this should be enough. All objects have __str__ but none of them subclass a string class. >> Or even better with a try except block as this will permit rebuilding >> objects that do not subclass Basic but that have args interface: > > I wonder why would one need to both have .args and not subclass Basic. > This seems a little bit artificial to me. Using Basic is artificial. In python what is important is the interface, not the class. Artificially forcing Basic everywhere completely breaks "duck typing", a technique used by all of the python community. I am not saying that we should not have a good class structure, however we should not impose it if the user does not want to use it. And most importantly, this rule of using Basic everywhere gives us absolutely no advantage. It only adds complexity. It is the same as using Float instead of just float. If you do not need this object for symbolical work, and on the contrary it only represents a hash that never gets into the symbolic machinery, you should just use float. In the same manner, if category theory is using sets just to contain stuff and does not need `subs` or whatever it should just use `set` - it is simpler and it is faster. -- 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.
