I'm not the one to authoritatively answer this, but I can guess...
I agree that the behaviour is inconsistent. I guess VPython could
reference the new vector instead of copying the contents to the
previous vector.
The downside would be:
b = vector(0,0,0)
a.pos = b
b.x = 3
This would change the value of a.pos but vpython wouldn't know to
update the graphics (without some tricks).
Otherwise "a.pos = b" could make a copy of b but that wouldn't be
consistent with normal assignment either.
Or if "b = a.pos" would make a copy, but there are still problems.
I've kinda experienced the problem but didn't identify the exact
reason as you did (thanks). You can get around the problem by making a
copy:
b = vector(a.pos)
I guess you want a copy rather than an alias anyway, because even with
normal sematics:
a.poo = vector(0,0,0)
b = a.poo
b.x = 4
print a.poo # ==> (4, 0, 0)
I don't see any good solutions other than avoiding to use
references/aliases to vectors.
Regards
/Anders Petersson
On Mon, Nov 3, 2008 at 9:38 PM, David Roundy
<ro...@ph...> wrote:
> Hello,
>
> I've been playing with vpython for a course I'll be teaching this
> winter, and have run into what seem to be broken semantics, which I'm
> afraid will confuse the heck out of my students (as it confused the
> heck out of me). Try to predict the outcome of the following program
> (run interactively, so you can see the value of b):
>
> from visual import *
> a = sphere()
>
> a.pos = vector(0,0,0)
> b = a.pos
> a.pos = vector(1,1,1)
> b
>
> a.poo = vector(0,0,0)
> b = a.poo
> a.poo = vector(1,1,1)
> b
>
> The result differs depending on whether we are dealing with a.poo or
> a.pos. a.poo behaves like native python while a.pos behaves in a very
> confusing manner. I hope this you consider this a bug! Is there any
> hope to get it fixed soon? Also, does anyone have an idea how to
> explain the assignment semantics to me?
>
> I spent a few months hating python semantics until finally I
> discovered that python is fine, it's vpython that's buggy. My current
> plan is to advise students never to put native vpython data members on
> the right hand of an = sign, since that's the only way I know of to
> avoid extreme frustration. Is there another approach that could work?
> It'd be much more elegant to actually use those data members as if
> they were real vectors, but I don't want to lead students into the
> land of extremely-confusing bugs. The idea of teaching in python was
> to avoid weird pointer aliasing bugs, not to make them harder to track
> down...
>
> David
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
|
