On Nov 17, 12:32 pm, "Brian Granger" <[EMAIL PROTECTED]> wrote: > This patch implements something quite different from what we had discussed:
Hi Brian, The implementation I submitted was the implementation I suggested in my original post. > * We never discussed changing the implementation of subs. I think > that is a separate discussion and it outside of the scope of changing > __call__. Personally, I think the syntax for subs is fine. You can still use subs the same way that you did before. All I did was add an additional syntax: f.subs(x=1,y=2) It seems like this is a reasonable thing to do. > * I thought we decided that __call__(*args, **kwargs) should not > simply be subs(*args, **kwargs). The reason for this is that calling > a function is a different thing conceptually from calling a function. I am not understanding what you are saying here (typo maybe). Could you clarify. > The following will be very confusing to users that are used to > python's call syntax: > > >>> f = x*y > >>> f(x,2) It is possible that only allowing the syntax f(x=1,y=2) is preferable rather than all things possible with subs. Having the shorthand f(...) support the full capability of subs was just a preference I had in implementing it. I am not too tied to the idea, but I think it could be handy at times. Maybe requiring an explicit subs is better. What do others think? > * I thought we had also decided to implement an entirely different > approach to handling the positional part of args. > > Do we need to have further discussion about what we all want to be > implemented, or do you just want to have a go at implementing the > original proposal. > > Just for reference, here is how I picture the positional syntax looking: > > >>> f = x*y > >>> f.bindings = (x,y) # This tells Basic how to order the *args part of > >>> __call__ > >>> f(2,3) > > 6 > > >>> f.bindings = (y,x) > >>> f(2, z) > > z*2 > > >>> f.bindings > > (y, x) > > >>> f.bindings = None > >>> f(2, 3) > > this should raise an exception saying that symbols have to first be > bound to the positional arguments. > > The name "bindings" could be something else, I just made that up. But > bindings would just be a property that the implementation of __call__ > uses when it gets a positional argument. I did note that you gave some suggestions of how one might implement positional args and it seems like a reasonable method, but from the thread it seemed like there were various objections to including an implicit args implementation. Since it was easy to add explicit args, and implicit args required more careful thought (on my part), I did not include this. I think the patch I submitted handles explicit substitution (i.e. f(x=1, y=2) ) as discussed on the thread. If we do decide to support positional args, I would suggest making this a part of the 'subs' method and forwarding from the __call__ method as done in the path. This makes for a consistent substitution syntax. There may be a good reason for f(...) to behave differently from f.subs(...), but I like the consistency of them behaving the same way. However, I would like to hear more from those that had objections to an implicit substitution syntax, particularly in regard to including a 'bindings' method as suggested. -Lance --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sympy-patches" group. To post to this group, send email to sympy-patches@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en -~----------~----~----~----~------~----~------~--~---
