prototyping good OOdesign in Python?

[Roman Suzi]

On 3 Jun 2002, Dean Goodmanson wrote:

(I oversaw this post and I feel I need to answer it)

> 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...

Hmmm... Who assesses the code quality? I guess if it is some very critical
software, its a case. But in other cases, who are there to tell you your
code is inacceptable as long as it works?

> 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.

Oh... 
 
> > 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.

Python is used extensively by RedHat Linux, for example.
Even install is governed by Python script (anaconda).

What is probably missing, is Python-based shell. 
(I recall there is Perl-based shell.)
(Hmmm. Can you imagine:

>>> cp file1 file2
>>> 

)
 
> 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...

Aren't there any standard thing to sort in C++?
Or are you speaking about sorting some fancy data?
 
> - 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.

Interesting idea.

> - 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

Sincerely yours, Roman A.Suzi
-- 
 - Petrozavodsk - Karelia - Russia - mailto:rnd at onego.ru -