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

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

I am a newbie to Python, and my experience
is limited to working with VPython and its objects.

Working as an end user (within the confines of the current
Python language and VPython objects), I was merely extending
the documentation's copyobjects() to work with
all of the display objects, which (except for label)
do seem to return a value for __members__ .
Certainly, a C++ copy constructor would be most efficient...
but I'm wearing the hat of an end user.

In addition, I am actually interested in selective copying of
objects and performing transformations on some object properties.
For instance, I'd like to create scenes which are coordinate-plane
projections of a full 3D scene, as in a CAD program.
Something else I'd like to do is to visualize a collision
in the lab-frame and from the center-of-mass frame.  
So, the scenes are not necessarily complete copies of each other.

As for the __methods__ attribute, I don't have any particular
need for this attribute.  I was merely [and possibly naively]
following a Python book I bought 
(the Visual Quicksart Guide (2002), p. 260),
which suggests that an object has at least three attributes
__dict__, __methods__, and __members__.


Now... looking over some of the older Python documentation, I found
http://www.python.org/doc/2.2.3/whatsnew/sect-rellinks.html#SECTION000320000000000000000
"2.2 Descriptors 
In previous versions of Python, there was no consistent way to discover 
what attributes and methods were supported by an object. There were some 
informal conventions, such as defining __members__ and __methods__ 
attributes that were lists of names, but often the author of an extension 
type or a class wouldn't bother to define them. ..."

...So, maybe it's time to find a new Python book.


Rob Salgado





Jonathan Brandmeyer wrote:
>
>
> 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