visualpython-users

[Visualpython-users] Backwards-compatibility problems in Visual 5

[Roberto A. M. <rha...@ho...>]

Hi:

I have made a few tests with Visual 5, and so far I have found the
following problems wich were not present in Visual 3:

- scene.title cannot be modifyied.
- scene.objects used to be a list, now it is a tuple? anyway, replacing
scene.objects with list(scene.objects) seems to work as good as Visual 3.
- AttributeError: 'display' object has no attribute 'cursor'

I am runnig VPython in Windows XP Professional.


Best regards,

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Visualpython-users] Backwards-compatibility problems in Visual 5

[Bruce S. <Bru...@nc...>]

See the documentation on displays, where you'll see that you can indeed 
change the title and other properties of a window, but you must make the 
window invisible first, then make it visible again. The rules in Visual 
3 for changing window properties were somewhat vague and inconsistent.

In the "What's new in Visual 5" you'll see listed as a known bug that 
scene.cursor isn't yet available.

I wasn't aware of a change from list to tuple for scene.objects, but 
clearly it ought to be a tuple, not a list, as this should not be a 
modifiable sequence. In what context did it matter that it was a list 
rather than a tuple?

Bruce Sherwood

Roberto Aguirre Maturana wrote:
> Hi:
> 
> I have made a few tests with Visual 5, and so far I have found the
> following problems wich were not present in Visual 3:
> 
> - scene.title cannot be modifyied.
> - scene.objects used to be a list, now it is a tuple? anyway, replacing
> scene.objects with list(scene.objects) seems to work as good as Visual 3.
> - AttributeError: 'display' object has no attribute 'cursor'
> 
> I am runnig VPython in Windows XP Professional.
> 
> 
> Best regards,
> 

Re: [Visualpython-users] Backwards-compatibility problems in Visual 5

[Roberto A. M. <rha...@ho...>]

> I wasn't aware of a change from list to tuple for scene.objects, but
> clearly it ought to be a tuple, not a list, as this should not be a
> modifiable sequence. In what context did it matter that it was a list
> rather than a tuple?
>

Like in the following example, when you need to recover the index of a  
previously picked object:


varCurrentObject = m.pick

(...)

#The following line gets an error on Visual 5, yet it works on Visual 3:
varCurrentObjectIndex=scene.objects.index(varCurrentObject)


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Visualpython-users] Backwards-compatibility problems in Visual 5

[Bruce S. <Bru...@nc...>]

Thanks. This looks like an incompatibility that we should fix.

Bruce Sherwood

Roberto Aguirre Maturana wrote:
>> I wasn't aware of a change from list to tuple for scene.objects, but
>> clearly it ought to be a tuple, not a list, as this should not be a
>> modifiable sequence. In what context did it matter that it was a list
>> rather than a tuple?
>>
> 
> Like in the following example, when you need to recover the index of a  
> previously picked object:
> 
> 
> varCurrentObject = m.pick
> 
> (...)
> 
> #The following line gets an error on Visual 5, yet it works on Visual 3:
> varCurrentObjectIndex=scene.objects.index(varCurrentObject)
> 
> 

Re: [Visualpython-users] Backwards-compatibility problems in Visual 5

[Bruce S. <Bru...@nc...>]

After some discussion with David Scherer, we're convinced that 
scene.objects should indeed remain a tuple in Visual 5.0, not a list. As 
he says, "Lists are mutable, so the user can try to do things like del 
scene.objects[2] and won't get any error message or indication that they 
are not doing the right thing. IMO error checking is MORE important than 
backward compatibility: hardly anyone will remember Visual 3 in a year, 
but people will make the same errors forever."

But I also have a question about the example code you show.

m.pick is the object picked, so you already know the object. What value 
is there in knowing the sequence position of this object in 
scene.objects, where the order of the objects is not relevant?

Bruce Sherwood

Roberto Aguirre Maturana wrote:
>> I wasn't aware of a change from list to tuple for scene.objects, but
>> clearly it ought to be a tuple, not a list, as this should not be a
>> modifiable sequence. In what context did it matter that it was a list
>> rather than a tuple?
>>
> 
> Like in the following example, when you need to recover the index of a  
> previously picked object:
> 
> 
> varCurrentObject = m.pick
> 
> (...)
> 
> #The following line gets an error on Visual 5, yet it works on Visual 3:
> varCurrentObjectIndex=scene.objects.index(varCurrentObject)
> 
> 

Re: [Visualpython-users] Backwards-compatibility problems in Visual 5

[Roberto A. M. <rha...@ho...>]

> After some discussion with David Scherer, we're convinced that
> scene.objects should indeed remain a tuple in Visual 5.0, not a list. As
> he says, "Lists are mutable, so the user can try to do things like del
> scene.objects[2] and won't get any error message or indication that they
> are not doing the right thing. IMO error checking is MORE important than
> backward compatibility: hardly anyone will remember Visual 3 in a year,
> but people will make the same errors forever."

I agree with most of the previous paragraph.


> But I also have a question about the example code you show.
>
> m.pick is the object picked, so you already know the object. What value
> is there in knowing the sequence position of this object in
> scene.objects, where the order of the objects is not relevant?
>

It is relevant, as long as the sequence itself is relevant.

Let's say that I'm taking GPS readings at regular intervals, marking a  
route, then i draw those points in VPython, in the very same order they  
where taken.

There are two ways I would like to access those points and getting any  
associated info to them: either merely pointing-and-clicking, Or navigate  
across the points sequence using keys defined as "Next" or "Previous". In  
the last case, since those points belong to a route, it is desirable to  
jump from point to point in the original order, either backwards or  
forward.

Best regard,

Roberto.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Visualpython-users] Backwards-compatibility problems in Visual 5

[Bruce S. <Bru...@nc...>]

In that case you should keep your own data structure with time sequence, 
because there's no guarantee that scene.objects will represent the 
objects in time-creation order.

Bruce Sherwood

Roberto Aguirre Maturana wrote:
>> After some discussion with David Scherer, we're convinced that
>> scene.objects should indeed remain a tuple in Visual 5.0, not a list. As
>> he says, "Lists are mutable, so the user can try to do things like del
>> scene.objects[2] and won't get any error message or indication that they
>> are not doing the right thing. IMO error checking is MORE important than
>> backward compatibility: hardly anyone will remember Visual 3 in a year,
>> but people will make the same errors forever."
> 
> I agree with most of the previous paragraph.
> 
> 
>> But I also have a question about the example code you show.
>>
>> m.pick is the object picked, so you already know the object. What value
>> is there in knowing the sequence position of this object in
>> scene.objects, where the order of the objects is not relevant?
>>
> 
> It is relevant, as long as the sequence itself is relevant.
> 
> Let's say that I'm taking GPS readings at regular intervals, marking a  
> route, then i draw those points in VPython, in the very same order they  
> where taken.
> 
> There are two ways I would like to access those points and getting any  
> associated info to them: either merely pointing-and-clicking, Or navigate  
> across the points sequence using keys defined as "Next" or "Previous". In  
> the last case, since those points belong to a route, it is desirable to  
> jump from point to point in the original order, either backwards or  
> forward.
> 
> Best regard,
> 
> Roberto.
>