It would be nice to have function overloading in Python... what about some kind of decorator to __new__ to filter the default args construction (and avoid calling all of __new__ functionalities)?
An inspiration might be: http://www.artima.com/weblogs/viewpost.jsp?thread=101605 On Monday, September 16, 2013 12:33:46 AM UTC+2, Aaron Meurer wrote: > > One thing you can do is allow different formats of the args. The > constructor does need to support the .args, but that doesn't have to > be the only format it accepts. Generally, I would say that the input > format should be friendly to the user and the .args format should be > friendly to code that wants to walk through the expression tree and > get at the parts of the expression. > > An example of this is Integral. The usual syntax that the user uses > for Integral is Integral(f(x, y), x, y) or Integral(f(x, y), (x, a, > b), (y, c, d)). But the .args look like (f(x, y), (x,), (y,)) or (f(x, > y), (x, a, b), (y, c, d)), i.e., in either case, the variables are > given as tuples. Thus, for instance, the first integration variable of > an integral is always integ.args[1][0], regardless of the type of the > integral. > > If some of the args information can be computed from the rest, I would > allow entering only the needed parts and then compute it all in .args. > You can also allow passing in the whole thing, so that it supports the > .args format, and in that case, don't recompute everything. > > If you do this, you should make sure that every format that you allow > is unambiguous, especially in corner cases. > > Regarding func, you can try it. You may run into some issues of code > that uses type(expr) instead of expr.func, but that code is wrong and > should be changed. You'll also need to make sure that your __eq__ and > __hash__ are implemented correctly. The default expr1 == expr2 iff > type(expr1) == type(expr2) and expr1.args == expr2.args won't work any > more. > > Aaron Meurer > > > On Sun, Sep 15, 2013 at 10:44 AM, F. B. <[email protected] <javascript:>> > wrote: > > > >> What is the class? Another option would be to make the super-class > >> simpler. My opinion is that .args should hold all relevant information > and > >> other fields should compute their values from .args by properties. > > > > > > I am working on subclassing TensorHead from the tensor module in the > > GammaMatrixHead object. Both are already merged into master. > GammaMatrixHead > > currently cannot be reconstructed from its args, as they are the args of > > TensorHead, but TensorHead args cannot be reduced, as they are required > to > > the tensor expressions. In the meantime, GammaMatrixHead has fixed > > properties to store in TensorHead (for example, the type of its > indices), so > > I avoided putting them into its __new__( ) constructor. > > > > I was thinking of overloading the func( ) method in GammaMatrixHead, > could > > work? > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "sympy" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to [email protected] <javascript:>. > > To post to this group, send email to [email protected]<javascript:>. > > > Visit this group at http://groups.google.com/group/sympy. > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
