On Fri, 06 Jun 2008, Michael J Gruber apparently wrote: > Gosh, I knew I got confused myself. As a matter of fact: There is no > "graphxy" right now, only "graph" and "graphxyz". Do you suggest > renaming graph as well? s/xy/xyz/g in (most of) what I submitted.
I was referring to the graphxy *class*, which I find appropriately named. > About the one-does-it-all function: The interface as it is > saves people from having to use lambda expressions. > I could do without that, it only creates trouble with > "context". I really think the emphasis on lambda expressions is a side-show: they are just functions. When the argument should be a function, the user is free to (but not required to) use a lambda expression. But I agree it would have been most natural to use real functions and forego string parsing. > I don't know about a more complex interface, though. It is not meant to be complex. I was just suggesting a unified interface that branches to existing code. > After all, all I wanted to do was providing a 3D function plot class. > The search for an appropriate name got me into that renaming trap. So starting with that observation, can I ask, why not start by only accepting functions, and leaving string parsing as a response to later user demands? (Which I do not expect you will see!) Also, even the whole parametric thing is redundant. Just accept one object. If it is a function, use it directly. If it is a tuple of three functions, use them for a parametric specification. (Being explicit about order is important of course.) Just a thought. Cheers, Alan ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ PyX-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pyx-devel
