visualpython-users

[Visualpython-users] further improved copyobjects() and a label BUG?

[Rob S. <sa...@ph...>]

My previous copyobjects() choked on curves [and labels].
Here's an improved version which works with curves.
See below for a possible bug with the label object.


def copyobjects(scene1,scene2):
    # based on http://www.vpython.org/webdoc/visual/options.html
    # Copy all Visual objects from scene1 into scene2
    scene2.select()

    scenelist=scene1.objects
    ###
    ### reverse() is needed so that the items in the destination list 
    ### of objects are in correspondence those of the source list
    scenelist.reverse()
    
    for obj in scenelist:
        newobj = obj.__class__() # create object in scene2

        if obj.__class__== 'curve':          ###
            for i in obj.pos:                ###
                newobj.append(pos=i)         ###

        for member in obj.__members__:
            if member == 'display': continue # avoid putting into scene1
            setattr(newobj,member,getattr(obj,member))


This function now seems to work for all of the "Basic Display Objects"
_except_ for the label object.


BUG?
	It appears that the label fails to return the __members__
	attribute.  Browsing the source code, it seems that:

	in label.cpp,
	Object Label::getattr(const char* _attr) is missing the case
		if (attr == "__members__") ....
	as one finds in prim.cpp and arrprim.cpp.

Here's an example (which fails):


from visual import *

earth=sphere()
print earth.__class__
print dir(earth)
print earth.__dict__
print earth.__methods__
print earth.__members__

print "==================="

earthlabel = label(text='Our Earth')
print earthlabel.__class__
print dir(earthlabel)
print earthlabel.__dict__
print earthlabel.__methods__
print earthlabel.__members__



Rob Salgado

Re: [Visualpython-users] further improved copyobjects() and a label BUG?

[Jonathan B. <jbr...@ea...>]

On Sun, 2003-09-28 at 16:34, Rob Salgado wrote:
> My previous copyobjects() choked on curves [and labels].
> Here's an improved version which works with curves.
> See below for a possible bug with the label object.
> 



> def copyobjects(scene1,scene2):
>     # based on http://www.vpython.org/webdoc/visual/options.html
>     # Copy all Visual objects from scene1 into scene2
>     scene2.select()
> 
>     scenelist=scene1.objects
>     ###
>     ### reverse() is needed so that the items in the destination list 
>     ### of objects are in correspondence those of the source list
>     scenelist.reverse()
>     
>     for obj in scenelist:
>         newobj = obj.__class__() # create object in scene2
> 
>         if obj.__class__== 'curve':          ###
>             for i in obj.pos:                ###
>                 newobj.append(pos=i)         ###
> 
>         for member in obj.__members__:
>             if member == 'display': continue # avoid putting into scene1
>             setattr(newobj,member,getattr(obj,member))
> 
> 
> This function now seems to work for all of the "Basic Display Objects"
> _except_ for the label object.
> 
> 
> BUG?

Maybe, maybe not.  

First off, only a handful of Python classes supply __members__ and
__methods__, so I'm not sure that we should be providing them at all.  I
think they are intruding on the interpreter's namespace, in much the
same way users should never define symbols with a leading _ in C (even
if several libraries do).

Secondly, if supporting an algorithm like that is all that they are
being used for, I think that there is a better solution.

Finally, I think that the above is a little hackish.  IMO the right
answer is to provide a copy constructor from C++.  Then, copyobjects()
looks like this:

def copyobjects( to_display, from_display):
	# Copies all displayobjects from from_display to to_display.
	
	displaylist = from_display.objects
	 # iterate across the list in reverse order.
	order.displaylist.reverse()
	for obj in scenelist:
		newobj = obj.__class__(obj)
		# newobj has identical properties to obj at this point.
		# Now move it to the new display.
		newobj.display = to_scene

Of course, that algorithm doesn't work right now, but it can with Boost
and a little effort on my part.

Comments?  Suggestions? 

Other than the purpose of copying objects' properties from one to
another, I am not aware of a good use for __methods__ and
__properties__.  What are you using them for?

-Jonathan Brandmeyer