You can subscribe to this list here.
2002 
_{Jan}

_{Feb}
(13) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}


2003 
_{Jan}

_{Feb}

_{Mar}
(2) 
_{Apr}

_{May}
(5) 
_{Jun}
(15) 
_{Jul}
(4) 
_{Aug}
(4) 
_{Sep}
(4) 
_{Oct}
(41) 
_{Nov}
(3) 
_{Dec}
(19) 
2004 
_{Jan}
(7) 
_{Feb}
(1) 
_{Mar}
(6) 
_{Apr}
(13) 
_{May}
(26) 
_{Jun}
(6) 
_{Jul}
(66) 
_{Aug}
(13) 
_{Sep}

_{Oct}
(21) 
_{Nov}
(12) 
_{Dec}
(24) 
2005 
_{Jan}
(7) 
_{Feb}
(24) 
_{Mar}
(9) 
_{Apr}
(5) 
_{May}

_{Jun}
(8) 
_{Jul}
(5) 
_{Aug}
(22) 
_{Sep}
(58) 
_{Oct}
(6) 
_{Nov}

_{Dec}
(2) 
2006 
_{Jan}
(1) 
_{Feb}
(11) 
_{Mar}
(12) 
_{Apr}
(8) 
_{May}
(12) 
_{Jun}
(30) 
_{Jul}
(6) 
_{Aug}
(2) 
_{Sep}
(6) 
_{Oct}
(1) 
_{Nov}
(1) 
_{Dec}
(1) 
2007 
_{Jan}

_{Feb}

_{Mar}
(1) 
_{Apr}
(2) 
_{May}

_{Jun}

_{Jul}
(8) 
_{Aug}
(3) 
_{Sep}

_{Oct}
(1) 
_{Nov}

_{Dec}

2008 
_{Jan}

_{Feb}

_{Mar}
(21) 
_{Apr}
(6) 
_{May}
(12) 
_{Jun}
(13) 
_{Jul}

_{Aug}

_{Sep}
(5) 
_{Oct}

_{Nov}
(4) 
_{Dec}

2010 
_{Jan}
(2) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(6) 
_{Jul}
(4) 
_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}
(3) 
2011 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(7) 
_{May}
(26) 
_{Jun}
(1) 
_{Jul}
(40) 
_{Aug}

_{Sep}

_{Oct}
(15) 
_{Nov}

_{Dec}
(2) 
2012 
_{Jan}

_{Feb}
(14) 
_{Mar}

_{Apr}

_{May}
(24) 
_{Jun}

_{Jul}

_{Aug}
(2) 
_{Sep}

_{Oct}
(9) 
_{Nov}
(3) 
_{Dec}
(2) 
2013 
_{Jan}
(12) 
_{Feb}
(8) 
_{Mar}

_{Apr}

_{May}
(3) 
_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(1) 
2014 
_{Jan}
(4) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2015 
_{Jan}
(2) 
_{Feb}

_{Mar}

_{Apr}
(1) 
_{May}

_{Jun}
(4) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(2) 
2
(2) 
3
(4) 
4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27
(1) 
28

29

30
(1) 
31
(3) 




From: Michael Schindler <mschindler@us...>  20040831 06:56:19

Hi, On 31.08.04, Joerg Lehmann wrote: > On 31.08.04, Andre Wobst wrote: > > On 30.08.04, Jörg Lehmann wrote: > > > apply deformers when drawing a path. Note that it is not clear > > > whether we first apply a trafo and then a deformer or vice versa > > > > One could argue, that a transformation is not that different from a > > deformer ... > Good point. I actually like this idea. We just have to derive > trafo.trafo from deformer.deformer and supply trafo.trafo with a > deform method. > In general, trafos and deformers do not commute. Therefore, the user should specify the order of appliance. For this, it would be the best to have trafos act as deformers. Good idea. Michael.  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
From: Joerg Lehmann <joergl@us...>  20040831 06:39:13

Hi, On 31.08.04, Andre Wobst wrote: > On 30.08.04, Jörg Lehmann wrote: > > apply deformers when drawing a path. Note that it is not clear > > whether we first apply a trafo and then a deformer or vice versa > > One could argue, that a transformation is not that different from a > deformer ... > > I do not yet claim, that we should do so, but we might at least > discuss this point of view. It would automatically lead to a solution > to this problem ... Good point. I actually like this idea. We just have to derive trafo.trafo from deformer.deformer and supply trafo.trafo with a deform method. Jörg 
From: Andre Wobst <wobsta@us...>  20040831 05:18:07

Hi, On 30.08.04, Jörg Lehmann wrote: > apply deformers when drawing a path. Note that it is not clear > whether we first apply a trafo and then a deformer or vice versa One could argue, that a transformation is not that different from a deformer ... I do not yet claim, that we should do so, but we might at least discuss this point of view. It would automatically lead to a solution to this problem ... André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ 
From: Andre Wobst <wobsta@us...>  20040830 06:40:24

Hi, you might be interested in my small note I just posted at http://wobsta.blogspot.com/ about a PyX developer meeting with Jörg last weekend. André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ 
From: SourceForge.net <noreply@so...>  20040827 20:48:44

Bugs item #986123, was opened at 20040706 20:01 Message generated for change (Comment added) made by wobsta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=986123&group_id=45430 Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Axis labels look weird Initial Comment: When I create an XY graph and specify an axis label that is more than one word long, sometimes the two words overlap. Here is ahat I have found so far: (Axis label specified: What it looks like) "X values"  Looks normal "Y values"  Looks normal "solution variable"  Two words overlap "variable"  Looks normal "variableABCDEFGHIJ"  Looks normal "variable ABCDEFGHIJ"  Looks like: variabl***CDEF GHIJ (where the *** indicates where the "e" and "AB" overlap) "solutionvariable"  Looks normal "solution_variable"  Gives the following error: Traceback (most recent call last): ... mycanvas.writeEPSfile(filename) File "/users/mont/PyX0.6.3/pyx/canvas.py", line 367, in writeEPSfile abbox = bbox is not None and bbox or self.bbox() File "/users/mont/PyX0.6.3/pyx/canvas.py", line 129, in bbox abbox = cmd.bbox() File "/users/mont/PyX0.6.3/pyx/deco.py", line 71, in bbox pbbox = self.path.bbox() File "/users/mont/PyX0.6.3/pyx/graph/graph.py", line 418, in bbox self.finish() File "/users/mont/PyX0.6.3/pyx/graph/graph.py", line 368, in finish self.domethods[0]() File "/users/mont/PyX0.6.3/pyx/graph/graph.py", line 310, in dolayout axis.finish(self.axespos[key]) File "/users/mont/PyX0.6.3/pyx/graph/axis/axis.py", line 344, in finish ac = self.painter.paint(axispos, self) File "/users/mont/PyX0.6.3/pyx/graph/axis/painter.py", line 486, in paint _title.paint(self, axispos, axis, ac=ac) File "/users/mont/PyX0.6.3/pyx/graph/axis/painter.py", line 305, in paint title = self.texrunner.text_pt(x, y, axis.title, titleattrs) File "/users/mont/PyX0.6.3/pyx/text.py", line 1133, in text_pt return self.text(unit.t_pt(x), unit.t_pt(y), expr, *args, **kwargs) File "/users/mont/PyX0.6.3/pyx/text.py", line 1115, in text self.execute(expr, self.defaulttexmessagesdefaultrun + self.texmessagesdefaultrun + texmessages) File "/users/mont/PyX0.6.3/pyx/text.py", line 944, in execute raise TexResultError("unhandled TeX response (might be an error)", self) pyx.text.TexResultError: unhandled TeX response (might be an error) The expression passed to TeX was: \ProcessPyXBox{\gdef\PyXHAlign{0.50000}\setbox0\hbox{$\vcenter{\vrule width0pt}$}\lower\ht0\hbox{{solution_variable}}% }{53}% \PyXInput{57}% After parsing the return message from TeX, the following was left: *! Missing $ inserted.<inserted text> $<to be read again> _<argument> ...h0pt}$}\lower \ht 0\hbox {{solution_ variable}}\ProcessPyXBox #1#2>\setbox \PyXBox =\hbox {{#1 }}\PyXDimenHAlignLT =\PyXHAl...<*> }{53} %! Extra }, or forgotten $.<argument> ...ower \ht 0\hbox {{solution_variable} }\ProcessPyXBox #1#2>\setbox \PyXBox =\hbox {{#1 }}\PyXDimenHAlignLT =\PyXHAl...<*> }{53} %! Extra }, or forgotten $.<argument> ...wer \ht 0\hbox {{solution_variable}} \ProcessPyXBox #1#2>\setbox \PyXBox =\hbox {{#1 }}\PyXDimenHAlignLT =\PyXHAl...<*> }{53} %! Extra }, or forgotten $.\ProcessPyXBox #1#2>\setbox \PyXBox =\hbox {{#1} }\PyXDimenHAlignLT =\PyXHAl...<*> }{53} %! Extra }, or forgotten $.\ProcessPyXBox #1#2>\setbox \PyXBox =\hbox {{#1}} \PyXDimenHAlignLT =\PyXHAl...<*> }{53} % My email address is alexander.mont@...  >Comment By: André Wobst (wobsta) Date: 20040827 22:48 Message: Logged In: YES user_id=405853 We can't reproduce this bug. I'm closing it for the moment. Please reopen it to provide us with further information.  Comment By: André Wobst (wobsta) Date: 20040707 08:18 Message: Logged In: YES user_id=405853 I expect this problem to be related to the text output itself. Could you try to run hello.py, which can be found at the example directory. You may substitute the string "hello, world!" by something you used before ("variable ABCDEFGHIJ") to reproduce your problem. In case you find the same behaviour it would be a much better suitable (e.g. minimal) example to further investigate your problem.  Comment By: Gert Ingold (gertingold) Date: 20040707 07:36 Message: Logged In: YES user_id=809523 I cannot reproduce the problem with "variable ABCDEFGHIJ" under PyX 0.6.3. Do you have a minimal example? The problem with "solution_variable" is not a PyX bug but related to TeX which expects the underscore in math mode where it would indicate a subscript (see also FAQ 4.3.3). To avoid this problem, the underscore has to be escaped with a backslash, i.e. you should use "solution\_variable". See also FAQ 2.4 concerning the use of raw strings in Python.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442886&aid=986123&group_id=45430 
From: Michael Schindler <mschindler@us...>  20040803 12:47:36

Hi, As far as I know this is what people use: 1. For the interpolation problem: Curves passing through given points: (A) smooth curves built by piecewise polynoms (parameterized by the spacial coordinates). This requires to solve quite large systems of linear equations  not a problem in principle, but the outcome is often poor because the polynoms are too restrictive. > IIRC Michael Schindler played with some smooth curve thru some given > points before already. I'm not sure whether any code is laying around > somewhere, which could be usefull in that respect. But in principle > you're right: it might be added on top of the existing PyX. for the case of equal spacing this problem needs no numeric solver, and I am planning to implement this as a graph.style.curve (B) parametric curves. In principle one gets nonlinear equations for the parameter values  a really hard problem. This requires a lot of information on the specific geometric case. Especially, using boundary constraints like a certain tangent of a curve or so is not straightforward formulated in terms of a general parameterization. This is maybe what Magnus Lie Hetland asks for. > > The curve construction reminds me of a feature (or set of features) > > from MetaPost that I believe is not available in PyX, but which can be > > quite nice... Basically, it's the spline stuff that tries to fit a > > curve to the points you give (without you having to give the Bezier > > contour points explicitly). Also, you can give such (very useful) > > constraints as the direction of the curve at a given point, and the > > spline will adapt to that. I assume this could quite easily be built > > on *top* of PyX  I just thought it might be nice to have it as an > > integrated part of the path mechanism? (I don't know the details of > > the splines used by MP/MF, but they look fine, IMO.) I do not know how metafont is doing that, but I think MF knows some generic cases and uses a kind of "optimal" parameterization  depending on the problem it has to solve. I do not even think that it is really an interpolating program  rather a mixture of interpolating and optimisation... Another example is finding the outline of brushes or enlarging arbitrarily shaped boxes. > > And another thing... I have no idea how it's done in MP (in MF I can > > sort of understand it) but MP allows you to use custommade paths as > > brushes in other parhts. Very nice for calligraphiclike looks, for > > example. (I guess one heavyhanded way of doing it would be simply to > > replicate the brush all along the path, with the appropriate spacing > > calcilated somehow, perhaps even dynamically along the path.) 2. Optimization problem: Approximating curves (C) Mainly used are extended bezier curves that have a wellspecified starting and ending point and try to pass through several other points on their way. To me this never looked very useful ... Maybe there is the "quadrature of the circle": The bezier curves depend linearly on their endpoints. For them one can build up a linear system of equations  again with some (linear) constraints ... This would merge the advantages of the (ordinary) splines and the parametric curves ... Does anyone know the name of this method or where to find this? I would say that this might be the most promising way to build a general algorithm in PyX for these nonstandard path operations. Michael.  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
From: Andre Wobst <wobsta@us...>  20040803 11:29:52

Hi, On 03.08.04, Magnus Lie Hetland wrote: > The curve construction reminds me of a feature (or set of features) > from MetaPost that I believe is not available in PyX, but which can be > quite nice... Basically, it's the spline stuff that tries to fit a > curve to the points you give (without you having to give the Bezier > contour points explicitly). Also, you can give such (very useful) > constraints as the direction of the curve at a given point, and the > spline will adapt to that. I assume this could quite easily be built > on *top* of PyX  I just thought it might be nice to have it as an > integrated part of the path mechanism? (I don't know the details of > the splines used by MP/MF, but they look fine, IMO.) IIRC Michael Schindler played with some smooth curve thru some given points before already. I'm not sure whether any code is laying around somewhere, which could be usefull in that respect. But in principle you're right: it might be added on top of the existing PyX. > And another thing... I have no idea how it's done in MP (in MF I can > sort of understand it) but MP allows you to use custommade paths as > brushes in other parhts. Very nice for calligraphiclike looks, for > example. (I guess one heavyhanded way of doing it would be simply to > replicate the brush all along the path, with the appropriate spacing > calcilated somehow, perhaps even dynamically along the path.) You're talking about pens, not fill patterns, right? I looked at this topic a few months ago after somebody asked me about it. In MetaPost you can do two kind of pen shapes: a polygon pen shape and a elliptic pen shape. For the first MetaPost calculates the boundary of the area to be stroked (i.e. filled, once the outline is calculated). While this is already a interesting part to program, the elliptic curve is quite different. MetaPost does not calculate a outline for that case (it would be an interesting challange, which seems to be related to the enlargment of arbitrary shaped boxes as we started to experiment in one of the test/experimental files some time ago). What metapost does is to draw the path with a circular pen (i.e. that's what PostScript does for a finite linewidth and round setting of linecap and linejoin). However, this drawing does not happen on the original path, but on a transformed path, where the transformation is the one to make the elliptic pen circular. To finally get the correct result, the transformation from the circular pen to the elliptic one is applied to the stroked path. That way you can stroke the path with a elliptic pen, but you can't calculated the outline. (AFAIK that's one of the problems people have to create outline fonts out of Metafont fonts.) > Sorry to turn yet another thread into one about possible features... > These are just a couple of things that came up when I took a stab at > implementing big, flexible braces (such as these: > http://just.letterror.com/ltrwiki/GlyphInterchangeFormat) in PyX. No problem. It's always interesting to look around ... André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ 
From: Magnus Lie Hetland <magnus@he...>  20040803 10:50:43

Andre Wobst <wobsta@...>: > > Hi, > > I just got some interesting links from a friend: That is indeed rather interesting. The curve construction reminds me of a feature (or set of features) from MetaPost that I believe is not available in PyX, but which can be quite nice... Basically, it's the spline stuff that tries to fit a curve to the points you give (without you having to give the Bezier contour points explicitly). Also, you can give such (very useful) constraints as the direction of the curve at a given point, and the spline will adapt to that. I assume this could quite easily be built on *top* of PyX  I just thought it might be nice to have it as an integrated part of the path mechanism? (I don't know the details of the splines used by MP/MF, but they look fine, IMO.) And another thing... I have no idea how it's done in MP (in MF I can sort of understand it) but MP allows you to use custommade paths as brushes in other parhts. Very nice for calligraphiclike looks, for example. (I guess one heavyhanded way of doing it would be simply to replicate the brush all along the path, with the appropriate spacing calcilated somehow, perhaps even dynamically along the path.) Sorry to turn yet another thread into one about possible features... These are just a couple of things that came up when I took a stab at implementing big, flexible braces (such as these: http://just.letterror.com/ltrwiki/GlyphInterchangeFormat) in PyX.  Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] 
From: Andre Wobst <wobsta@us...>  20040803 08:39:01

Hi, I just got some interesting links from a friend: On 03.08.04, Rolf Niepraschk wrote: > The GlyphInterchangeFormat (or GLIF) is a simple and clear XML > representation of a single glyph. It is a major part of the RoboFab > project, and it is the foundation of the UnifiedFontObject. GLIF files > usually have a ".glif" extension. > > ==> http://just.letterror.com/ltrwiki/GlyphInterchangeFormat > > RoboFab is a library of python code for manipulation and storage of font > and glyph related data. RoboFab implements a new font file format, the > UnifiedFontObject(s) or .ufo for short. > > ==> http://just.letterror.com/ltrwiki/RoboFab > > The UnifiedFontObject (or UFO) is a two headed beast. It is both a file > format (see specification below) and a python scripting interface (see > short description below) for dealing with font related data. Here's some > general info: http://www.letterror.com/code/robofab/ufo.html > > ==> http://just.letterror.com/ltrwiki/UnifiedFontObject > > > ...Rolf >  >  Rolf Niepraschk c/o PhysikalischTechnische Bundesanstalt  >  Abbestr. 212; D10587 Berlin, Germany  >  Tel/Fax: ++49303481316/490, email: Rolf.Niepraschk@...  André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ 
From: Andre Wobst <wobsta@us...>  20040802 08:59:17

Hi, On 02.08.04, Andre Wobst wrote: > some fancy examples would be great as well ... Something like the enclosed one, which looks pretty well, but unfortunately it does use the solver to calculate the crossing point between two lines only ... André PS: Do not forget to fetch the latest version of solve.py before trying the example since I broke some multiplication logic due to the vector*matrix multiplication yesterday and the linear equation solver used an integer matrix by accident.  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ 
From: Andre Wobst <wobsta@us...>  20040802 05:47:09

Hi, On 01.08.04, Magnus Lie Hetland wrote: > > One structually missing thing is the "redefinition" of an equation, > > but this should not be hard to add it to the solver. > > No  and in a pinch, you could basically just build a new solver with > one equation redefined. I thought about that as well before, but there seems to be a problem: If you create several solver instances (which is trivial, of course), you can't store the solver results in the scalars itself. You would loose to know, whether a scalar is a constant or it got set by another solver (and should be overwritten?). We can find some way out of this problem, but it might be quite obscure to the user ... Beside that there are quite some other things to be discussed. Just a few which come into my mind immediately: In MetaPost you can define equations, which overdetermine the problem. You can do so by nonescalar equations and I think it's a bad idea to do so, but this might be discussed with people, who are used to the MetaPost equation solver. I'm not sure whether this is a often used feature and whether we should spend time on that at all. Currently the integration in PyX is not thought about. We have at least to think about the interfaces to the path stuff, the transformations and the PyX lengths. And we might think about the basic functionality. Currently I've tried to implement some schoollike vector algebra. For example we do have vectors and we can do scalar products between vectors. Multiplying a vector by another vector will lead to a scalar product. One could also think about introducing dual vectors, so that multiplying a dual vector by a vector will be a scalar product, but multiplying a vector by a dual vector will be a dyadic product and result in a matrix. While there would be *some* people how would like that (I think, I would join that portion), it might be inappropriate to our goals using the system for geometrical operations. So, yes, I think we should stick on what we already have (up to introducing a full transformation), but I'm not totally sure. Beside that we'll need to complete the tests and some fancy examples would be great as well ... André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ 
From: Magnus Lie Hetland <magnus@he...>  20040801 20:40:53

Andre Wobst <wobsta@...>: > [snip] > Coming back to our MetaPost like equations I've just checked in yet > another version, where there are scalars, vectors, and matrices now. > You can define a matrix by equations like in MetaPost, i.e. which > points should be transformed into which points (except for the missing > translation; a matrix is not a full affine transformation, It can be... If you use homogenous coordinates :) > but building a trafo class on top of a matrix and a vector should be > quite easy). Yeah  or just hiding the homogenous coordinates behind the scenes. > You can also calculate the invers of a matrix by multiplying it to > another matrix and set the result to the uniform matrix ... so in > principle we should be able to do most of the things you can do in > MetaPost now. Sounds veeery goood !) > One structually missing thing is the "redefinition" of an equation, > but this should not be hard to add it to the solver. No  and in a pinch, you could basically just build a new solver with one equation redefined. > Andr=E9 =20 Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] 
From: Andre Wobst <wobsta@us...>  20040801 20:29:56

Hi, On 30.07.04, Magnus Lie Hetland wrote: > [snip] > > > point([1, 2, 3]) > > > > > > or > > > > > > point((1, 2, 3)) > > > > > > is completely irrelevant (as long as you stay away from the > > > naughtiness of type checking ;). > > > > I'm not so sure. To me it makes a difference. > > Not unless you're doing type checking ;) > > I'm talking from the perspective of the function, not the caller. The > function should simply treat the argument as a sequence, and not > bother with how it is implemented. Sure, that's right. My points were not related to the isinstance discussion we actually started at. > The only use of tuples, IMO (as a Python type, not as a concept  you > could easily use a list to model a mathematical tuple, where each > position has a specific meaning and so forth) is that they are > hashable, and thus can be used as keys in dicts, members of sets and > so forth. You have the same dichotomy (list vs. tuple) in the set > implementation (with set and frozenset). I see, the hasability is an important point. I pretty much like your comparision to set and frozenset. It looks like a very reasonable point of view ... > What do you mean? Would you like to use several iterable objects as > arguments to list(), for example? What would that mean? Something like > list(chain(iter1,iter2,iter3))? (The chain function is available in > the itertools module.) I meant list(*chain(iter1, iter2, iter2)). I would really like to be able to write list(*iter1, *iter2, *iter3). Suppose we have the line function line(x1, y1, x2, y2) as it is defined in PyX. Having a function point(...) returning a list (x, y), it would be great if we could just write line(*point(...), *point(...)). Currently you have to write line(*(point() + point()), which I don't understand why ... Coming back to our MetaPost like equations I've just checked in yet another version, where there are scalars, vectors, and matrices now. You can define a matrix by equations like in MetaPost, i.e. which points should be transformed into which points (except for the missing translation; a matrix is not a full affine transformation, but building a trafo class on top of a matrix and a vector should be quite easy). You can also calculate the invers of a matrix by multiplying it to another matrix and set the result to the uniform matrix ... so in principle we should be able to do most of the things you can do in MetaPost now. One structually missing thing is the "redefinition" of an equation, but this should not be hard to add it to the solver. André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ 