On Fri, Jun 22, 2012 at 6:45 PM, [email protected] <[email protected]> wrote: > >> 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.
Well, yes, I see (I did search, thank you for the remark), however, I remember that someone on the list said that duck typing is inherently disabled (or at least not that widely used) in SymPy class infrastructure, and this matches my own experience with SymPy (which is small, without any doubt). If this is true, then trying to nevertheless push duck typing in some cases and avoiding it in other cases looks rather inconsistent to me. >>> 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. Hm, in a continuation to what I have said above, I wonder how far one can go in trying to stay away from SymPy class hierarchy and get some useful code. Not very far, I guess, since, from what I have seen, quite a lot of things depend on the object being properly integrate in the SymPy class hierarchy (including the tests in test_args.py). If we talk about simple ad-hoc user objects, then indeed, keeping that out of the SymPy class hierarchy requires less code. However, frankly, subclassing from Basic is trivial in most cases. And if one wants to store an object which is hard to subclass from Basic (e.g., a mutable object) in, for example, a FiniteSet, I'd say that that is rather bad. > And most importantly, this rule of using Basic everywhere gives us > absolutely no advantage. It only adds complexity. Well, that maybe is so, I am far from being in a position to judge, of course. However, since a great part of SymPy currently grows from Basic, I guess that deviating from that in the small particular case of FiniteSet is inconsistent. > 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. Well, as I said, I used Float just as a valid subclass of Basic which could give me a sort key for free. It could just as well have been Tuple; I guess the fact that I chose Float was misleading. However, as I said in one of the previous messages, now I'd rather stop using Float and rather construct the sort key by hand. > More examples: > > check the XFAILed test in test_args I have taken a look at a couple of the corresponding classes; unfortunately, I cannot really understand off-hand what the reason for @XFAIL-ing was, since I don't really understand the semantics. My own (recent and obviously reduced) experience with having my classes pass test_args included a redesign of the class hierarchy, which resulted in better, shorter, clearer code. Not that I say that the classes for which the tests are @XFAIL-ed are badly designed; it's just that I can't understand the reasoning between not fully complying with Basic. Thank you for pointing out the classes, though. > check the comments in the private alternative of sympify Do you refer to the sympify in your branches? I can only see one simplify in master. Sergiu -- 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.
