A couple of OOPython questions

[Michael Chermside]

Alexy Khrabrov writes:
> Reading python books feels a bit like reading Perl books -- although
> OO is there, some fundamental questions are not illuminated, and then
> OO comes after scripting or text, as in the Cookbook!

Good point. Many Python tutorials start with simple scripts because 
they're shorter, and save OO for later. It's a bit misleading because
short scripts may be easier to learn on, but most coding is done on
larger systems, where OO is very useful.

> E.g., a = b is a deep copy.

No, that's not true. The line "a = b" binds the name 'a' to the
object that the name 'b' is currently bound to. Nothing is copied.
Well, depending on implementation, perhaps some pointer somplace is
copied, but no PYTHON object is copied -- a and b will refer to the
same object.

> What are the equivalent of copy constructors?

Python has no equivalent, because all objects live "on the heap" and
are referenced via name binding.

> Here's another OO question for some real-life application, not that
> puny regex fun (or was that perl? :)...  I've developed a CORBA server
> for structural protein data, 
      [...]
> OK, now I go to my python prompt and I want to inspect my objects as
> returned by the CORBA server.  One of them represents an atom site.  I
> merrily type just its name to see the great unknown unwrap before my
> eyes.  Here:
> 
> >>> a
> <MMS.StructConf instance at 0x8cb1b44>

Aha... sounds like you want a way of printing out the full structure
of some object. Simply calling repr() on it (that's what gets printed
after each line of input) won't do that, at least not in the general 
case (simple lists and dicts DO dump their full contents to repr(),
but many objects don't).

Actually, the general problem is quite hard. What about objects which
contain OS-specific data (eg: file pointers). What about objects that
contain references to themselves (which is more common than you might
think)? One thing which I strongly recommend you to try is to get 
Python 2.3 and try out the version of Idle that comes with it. Start
it up and then try "Stack Viewer" from the Debug menu. It's exactly
the kind of thing you are thinking of here, except that instead of
printing it all out it provides a tree you can drill down into.

  [...]
> Printing out gazillion fields by hand for each class is silly, they
> only wrap strings and numbers and other objects of that nature.  I am
> ready to dive in a recursive descent.  No such luck -- whoever created
> CORBA bindings for python didn't make those objects dictionary-like!
  [...]
> Is there an easy way to write something _once_, general enough, to
> print out a hierarchy of nested objects which just don't have
> __getitem__, although every field is either a string or a number or
> another object?

Well, I'm sure there is SOME way to obtain them, but since I'm not
familiar with the omniORBpy objects, I'm not quite sure how. And
without knowing how to access them, I can't provide you with sample
code. But check out the trick I decribe above for Idle... I think it
may help you out.

-- Michael Chermside