From: Magnus L. H. <ma...@he...> - 2004-07-29 11:09:02
|
Andre Wobst <wo...@us...>: > > Hi, >=20 > On 28.07.04, Magnus Lie Hetland wrote: > > Joerg Lehmann <jo...@us...>: > > > > > [snip] > > > IMHO it's too implicit. In particular, not having to explicitly spe= cify > > > the solver is probably not a good idea.=20 > >=20 > > I think using =3D=3D 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 =3D=3D y: alwaysexecuted()..= .) >=20 > Thanks, J=F6rg, Magnus. I was not satisfied myself. The comparison make= s > 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. Comparing numbers usin 'is' is probably not a good idea, as this behavior isn't (AFAIK) defined as part of the language -- it's an implementation detail that might change. > > If one was feeling adventurous, one could even do stuff like > >=20 > > solver(x =3D y) > >=20 > > but only for single-variable left-hand-sides, of course. >=20 > I do not quite understand. What's the result of an assignment? No, no -- the above is just the use of a keyword argument. [snip] > Beside that, I think where might be usecases, where you store a term. > Say: >=20 > x =3D scalar() > y =3D scalar() > z =3D scalar() >=20 > A =3D x + 5*y > B =3D A + y > C =3D A + z >=20 > solver.eq(B, C) >=20 > I don't know whether this will make sense, but you can do so. This looks just fine to me. [snip] > You can currently do so with the "=3D=3D" logic. Yeah, I meant specifically fiddling with things so you could use '=3D' (which you normally couldn't do -- not in the same way you do with '=3D=3D'). [snip] > Now you can write: >=20 > a =3D=3D point(0, 1) >=20 > Guess, what b becomes? ... ;-) Hehe. BTW: I wrote pt to work like a sequence, and thus have a constructor of the type pt([1, 2 ,3]) and not pt(1, 2, 3). This was motivated by a similar discussion about the new set type. I guess it is sort of echoed by the discussion of the use of explicit lists in the decorator specifications in PyX. Just food for thought... > Andr=E9 --=20 Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] |