# Just Launched: You can now import projects and releases from Google Code onto SourceForge

We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps.

## Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental solve.py,1.2,1.3

 Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental solve.py,1.2,1.3 From: Andre Wobst - 2004-07-29 06:11:39 ```Hi, On 28.07.04, Magnus Lie Hetland wrote: > Joerg Lehmann : > > > [snip] > > IMHO it's too implicit. In particular, not having to explicitly specify > > the solver is probably not a good idea. > > I think using == for anything with side-effects (or even anything that > isn't interpretable as a boolean equality check) is quite unfortunate. > It might *look* good, but still... (if x == y: alwaysexecuted()...) Thanks, Jörg, Magnus. I was not satisfied myself. The comparison makes me troubles as well ... see the id comparision and the XXX comment, where I check for zero using "is", which works, since all integer constants below 100 are predefined and used by reference. In the beginning I liked the idea, but its probably a bad idea. > If one was feeling adventurous, one could even do stuff like > > solver(x = y) > > but only for single-variable left-hand-sides, of course. I do not quite understand. What's the result of an assignment? Anyway, once we do not use x == y, we should allow for x = y as well. Its becoming even less symmetric: Currently you need to set x and y to be scalar instances (or variable instances). In your case this becomes assymetric. You would need to initialize just x. Beside that, I think where might be usecases, where you store a term. Say: x = scalar() y = scalar() z = scalar() A = x + 5*y B = A + y C = A + z solver.eq(B, C) I don't know whether this will make sense, but you can do so. > It would be possible to do some property magic too... I'm pretty sure > I could write code such that > > a.x = b.y > a.y = b.x > > could be turned into a set of equations (by using wrapper classes > around the objects returned by the properties, somewhat like bound > methods). > > Just musing. You can currently do so with the "==" logic. That's because the components of a vector ar scalars and you can formulate scalar eqations and vector equations. So you can currently write: a = vector(2) b = vector(2) a[0] == b[1] a[1] == b[0] Note I have not (yet) a getattr on the vectors for "x", "y", "z". But right, thats trivial to be added. Now you can write: a == point(0, 1) Guess, what b becomes? ... ;-) André -- by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ ```