prototyping good OOdesign in Python?
Roman Suzi
rnd at onego.ru
Thu Jun 6 03:35:06 EDT 2002
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 -
More information about the Python-list
mailing list