prototyping good OOdesign in Python?

[Dean Goodmanson]

Ken Seehof <kseehof at neuralintegrator.com> wrote in message \
> > Maybe this was already discussed, but I'd liked to raise this topic again.
> >
> > Python has superb OOProgramming support. Lets not dispute this for a
> > moment. Now let's consider that we need to make well-designed OOP solution
> > first prototyped in Python.
> >
> > What troubles are there? Python is too dynamic and all that. And all
> > those nifty features need to be translated properly into, say, C++.
> >

Wow! A topic that I have a keen interest in and slight experience in!

re troubles...

- Implementing the design in Python using idioms that translate into
stuff only possible through extraneous C++ code and/or STL.
(range->foreach'isms, function pointers, ... mind is blanking ...
python's data types and support sure are handy, but it does take a few
extra brain cycles to write them in a C/C++ shop fashion (note the C,
in my experience only 20% of the advanced C++ topics are implemented
by 80% of the shop, and the other code is given the black-art
skepticism...in retrospect, that's a similar glare some folks get when
mentioning Python. *sigh*)  "Making Python look like C++" might not be
smart if you have the opportunity to keep the Python "Prototype".

I was hoping to seperated design from implementation in my
enumerations, but it doesn't look like that's going to happen at this
hour.

- Exception Handling & Asserts: Here I hope it's very similar.  Sorry,
wasn't a requirement in my world, no specific advice. Project advice
Include it in your original code & design prototype --adding it in
later is the dreams turn sour, but it sounds like you've got
appropriate time for up-front design.

> Maybe this has already been discussed

I didn't go looking. If you do, please post the links.    I'm waiting
for a software development book which uses Python for
design/prototyping, unit testing, building & system testing *non
Python projects*.

I do have lofty dreams of Python filling the role of Windows VBScript
& friends to Unix scripting tools.

Back to the topic...

- I got bit by Python shortcuts.  Looping and Sorting an array.  It
was so simple in python that it turned into an "assumption" in my
prototype and was dropped when I coded the C++ version.  A smack on
the forehead later and I started figured out how to sort my vector...

- I'm not sure if this needs saying, but... STL is nifty and
translates, but debugging is much harder than the comparable idioms in
Python. Schdule time  for creating debugging support code in those
objects. (if not for you, your peers)

- I succesfully tested a sub-system in a Python test harness that
allowed me to find bugs in it, protocol improvements, and that first
wave of implementation perspective before my writing any of my C++
code.
I didn't get to SWIG/Boost/etc. wrapping my C++ for further tests.
*sigh*    On that note, you  may want to peruse the boost.org/python
documentation ( http://boost.org/libs/python/doc/index.html ) and the
mailing list for a closer look at mapping C++ to Python.

If you DO built unit tests in Python for your Python API, the majority
should be re-usable in your python wrapped C++ implementation.

- Finally, note data inputs as reading and interacting from different
sources (existing libraries, goofy database connections, ??) might
take double time mapping prototype (python) and your implementation
(c++) to the source, along with who-knows-what "marshalling" issues.

Worse comes to worse, keep that shell handy as working out a small
problem in python sure beats Visio and Excel. (actually, unless your
reallly fast, I still used a spreadsheet for tabular perspective &
printing on data dumps.)

As you can see, I've contributed more cue's than facts.  You're quest
is a noble one, good luck in balancing research time with
hammer-it-out-ignore-redudancies-just-get-it-done time.

Maybe I should go back and read your code some more...
...maybe I should sleep.

Night,

Dean