## Re: [PyX-user] Simply Draw

 Re: [PyX-user] Simply Draw From: Andre Wobst - 2005-09-16 13:36:58 ```On 13.09.05, Armin Straub wrote: > > That's fine, but you may spend some time whether you really want to > > introduce such a different meaning. If you really want to do so I'll > > not complain. You're free to do so, but I ask you to at least spend a > > few seconds before doing you final decision ... ;-) > > I'm thinking about it... If I now understand the problem correctly, the > current implementation is bad mainly because > - it fixes the order > - and the name of the axes involved. Right. > I have solved (at least I hope so) the issue of fixed order using the > following code snippet > if expression.func_code.co_varnames == ('y',): > string = "x(y)=expression(y)" > else: > string = "y(x)=expression(x)" > which should yield some more symmetry in the sense that it does matter whether > a function is defined as > f = lambda x: sin(x) > versus > f = lambda y: sin(y). This works, yes, but I don't really like it. It seems too implicit to me. We had such an implicit definition by parsing the string and getting the axis name out of it in earlier versions (like "y=sin(x)"), but now we have it I much more like the very explicit form "y(x)=...". Still even in our old version we had the axis name explicitly given in the string expression. However, as long as we use a string we'll always need the context to access extern functions, right. So my currently preferred solution still is to have the function as it is for the common case with arbitrary names and a functionxy for the most frequent use-case with predefined names for a an external function with signature "y(x)=...". I would think of it just as an handy shortcut. Beside that I thought about a dynamism for functionXY, where XY could be anything. But the problem is, that we (1) dont't know where to split it and (2) we can't do a __getattr__ on module-level to implement something like that. While one could try to simulate that, I would not like such a solution, which is too fancy. > This issue does not really appear for paramfunction since all you have to do > for swapped axes is to return the values (x,y) swapped. So there is at least > from a functional point of view little to gain (although I might be wrong > here...). Right. I don't see any use-case either where the order is that problematic. > Just a note to the named axes. If this would be wanted one could take the > function name into account (not useful for lambda style functions though) to > allow for some settings, but I can't think of a really useful and obvious way > (and that's what it should be in my opinion). This is even more implicit and break for lambda functions. I don't like it either. Hmm. André -- by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ ```