prototyping good OOdesign in Python?
Roman Suzi
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++.
Recently I encountered the following piece of code
(from Arts++ project):
//===========================================================================
// Copyright Notice
//
// By accessing this software, arts++, you are duly informed
// of and agree to be bound by the conditions described below in this
// notice:
//
// This software product, arts++, is developed by Daniel W. McRobb, and
// copyrighted(C) 1998 by the University of California, San Diego
// (UCSD), with all rights reserved. UCSD administers the CAIDA grant,
// NCR-9711092, under which part of this code was developed.
//
// There is no charge for arts++ software. You can redistribute it
// and/or modify it under the terms of the GNU Lesser General Public
// License, Version 2.1, February 1999, which is incorporated by
// reference herein.
//
// arts++ is distributed WITHOUT ANY WARRANTY, IMPLIED OR EXPRESS, OF
// MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE or that the use
// of it will not infringe on any third party's intellectual
// property rights.
//
// You should have received a copy of the GNU Lesser General Public
// License along with arts++. Copies can also be obtained from:
//
// http://www.gnu.org/copyleft/lesser.html
//
// or by writing to:
//
// Free Software Foundation, Inc.
// 59 Temple Place, Suite 330
// Boston, MA 02111-1307
// USA
//
// Or contact:
//
// in...@caida.org
//===========================================================================
// constructor
............skip
Arts::Arts()
{
this->_data._ipPath = (ArtsIpPathData *)0;
this->_data._asMatrix = (ArtsAsMatrixData *)0;
this->_data._netMatrix = (ArtsNetMatrixData *)0;
this->_data._portTable = (ArtsPortTableData *)0;
this->_data._portMatrix = (ArtsPortMatrixData *)0;
this->_data._protocolTable = (ArtsProtocolTableData *)0;
this->_data._selectedPortTable = (ArtsSelectedPortTableData *)0;
this->_data._interfaceMatrix = (ArtsInterfaceMatrixData *)0;
this->_data._nextHopTable = (ArtsNextHopTableData *)0;
this->_data._bgp4RouteTable = (ArtsBgp4RouteTableData *)0;
this->_data._rttTimeSeriesTable = (ArtsRttTimeSeriesTableData *)0;
this->_data._tosTable = (ArtsTosTableData *)0;
#ifndef NDEBUG
++_numObjects;
#endif
}
Arts::Arts(const Arts & arts)
{
this->_header = arts.Header();
this->_attributes = arts.Attributes();
switch (this->_header.Identifier()) {
case artsC_OBJECT_IP_PATH:
this->_data._ipPath = new ArtsIpPathData;
assert(this->_data._ipPath != (ArtsIpPathData *)0);
*(this->_data._ipPath) = *(arts.IpPathData());
break;
case artsC_OBJECT_AS_MATRIX:
this->_data._asMatrix = new ArtsAsMatrixData;
assert(this->_data._asMatrix != (ArtsAsMatrixData *)0);
*(this->_data._asMatrix) = *(arts.AsMatrixData());
break;
case artsC_OBJECT_NET:
this->_data._netMatrix = new ArtsNetMatrixData;
assert(this->_data._netMatrix != (ArtsNetMatrixData *)0);
*(this->_data._netMatrix) = *(arts.NetMatrixData());
break;
case artsC_OBJECT_PORT:
this->_data._portTable = new ArtsPortTableData;
assert(this->_data._portTable != (ArtsPortTableData *)0);
*(this->_data._portTable) = *(arts.PortTableData());
break;
case artsC_OBJECT_SELECTED_PORT:
this->_data._selectedPortTable = new ArtsSelectedPortTableData;
assert(this->_data._selectedPortTable != (ArtsSelectedPortTableData *)0);
*(this->_data._selectedPortTable) = *(arts.SelectedPortTableData());
break;
case artsC_OBJECT_PORT_MATRIX:
this->_data._portMatrix = new ArtsPortMatrixData;
assert(this->_data._portMatrix != (ArtsPortMatrixData *)0);
*(this->_data._portMatrix) = *(arts.PortMatrixData());
break;
case artsC_OBJECT_PROTO:
this->_data._protocolTable = new ArtsProtocolTableData;
assert(this->_data._protocolTable != (ArtsProtocolTableData *)0);
*(this->_data._protocolTable) = *(arts.ProtocolTableData());
break;
case artsC_OBJECT_TOS:
this->_data._tosTable = new ArtsTosTableData;
assert(this->_data._tosTable != (ArtsTosTableData *)0);
*(this->_data._tosTable) = *(arts.TosTableData());
break;
case artsC_OBJECT_INTERFACE_MATRIX:
this->_data._interfaceMatrix = new ArtsInterfaceMatrixData;
assert(this->_data._interfaceMatrix != (ArtsInterfaceMatrixData *)0);
*(this->_data._interfaceMatrix) = *(arts.InterfaceMatrixData());
break;
case artsC_OBJECT_NEXT_HOP:
this->_data._nextHopTable = new ArtsNextHopTableData;
assert(this->_data._nextHopTable != (ArtsNextHopTableData *)0);
*(this->_data._nextHopTable) = *(arts.NextHopTableData());
break;
case artsC_OBJECT_BGP4:
this->_data._bgp4RouteTable = new ArtsBgp4RouteTableData;
assert(this->_data._bgp4RouteTable != (ArtsBgp4RouteTableData *)0);
*(this->_data._bgp4RouteTable) = *(arts.Bgp4RouteTableData());
break;
case artsC_OBJECT_RTT_TIME_SERIES:
this->_data._rttTimeSeriesTable = new ArtsRttTimeSeriesTableData;
assert(this->_data._rttTimeSeriesTable != (ArtsRttTimeSeriesTableData *)0);
*(this->_data._rttTimeSeriesTable) = *(arts.RttTimeSeriesTableData());
break;
default:
break;
}
#ifndef NDEBUG
++_numObjects;
#endif
}
..........skip the rest of file - there are 2-3 more similar
.......... switch-constructs.
------------------------------------------------------------
This code looks like... automatically generated. Rather than manually
written. I do not know why it was written in C++ at all. Of course, I
imagine 2-3 variants of how to refactor it if I were writing the code
in Python. I am pretty sure there were no select statement (switches)
in Python code, because that is what polymorphism is about.
But then again, translating back to C++ could be difficult. The
mentioned example is all about reading a specially formatted binary
file to produce certain slices of information. And for each
class it uses separate .cc/.hh file! While all the difference
between different classes - structure of corresponding data entries.
My approach in this case could be one resource file, with format
specification (like DTD). Plus one univarsal class to handle big
binary file according to "DTD"). Plus maybe separate resource file
with data query specifications. And it could be at most 80 Kb Python
project, not that monster Arts++ is in both source and binary forms...
Well, if you still follow this thread, the question is - how well
Python could serve as an ARCHITECTURAL prototype if it has too rich
OOP facilities? That is, is Python of help when trying to
prototype certain design? Developing in C++ looks so unnecessary hard
after things were done in Python...
Or, it may be put this way: what discipline a Python programmer must
obey to allow it's prototype to be conveniently rewriten in C++?
The above thoughts aren't probably well-formed. But I hope
my concern is understood.
Sincerely yours, Roman Suzi
--
\_ Russia \_ Karelia \_ Petrozavodsk \_ r...@onego.ru \_
\_ Saturday, June 01, 2002 \_ Powered by Linux RedHat 7.2 \_
\_ "Tried to play my shoehorn... all I got was footnotes!" \_
Ken Seehof
I agree with what you are saying. Here's my approach :-)
0. Write a project schedule for management; something like this:
1. Prototype in python
2. Convert to C++
1. Prototype in python
2. Give a nice demo, and convince management to skip step 2
3. Re-implement a few cpu intensive classes in C++
Since most of the code never /actually/ gets rewritten in C++,
the need for special C++ "discipline" in the python code goes
away. Weeks are slashed from the schedule, and the program is
more maintainable.
Another nice advantage is that the python programmer gets to ask
for a raise, and has excellent job security!
There may be a few oddball examples of projects that actually
need to end up written in C++ after prototyping in python, but
for the most part, the most common reason to target C++ is to
alleviate fear of the unknown. (Hmm, is this also why people,
(including myself), still buy from Microsoft? :-)
- Ken Seehof
Sean 'Shaleh' Perry
> Well, if you still follow this thread, the question is - how well
> Python could serve as an ARCHITECTURAL prototype if it has too rich
> OOP facilities? That is, is Python of help when trying to
> prototype certain design? Developing in C++ looks so unnecessary hard
> after things were done in Python...
> Or, it may be put this way: what discipline a Python programmer must
> obey to allow it's prototype to be conveniently rewriten in C++?
>
> The above thoughts aren't probably well-formed. But I hope
> my concern is understood.
>
architectural prototyping is what I usually use python for when I prototype,
the other use is rapid class creation for behaviour testing. You have to keep
in mind the goal of eventually porting to C++ but it is a prototype so there is
not a lot of code there anyway.
Delaney, Timothy
>
> >Since most of the code never /actually/ gets rewritten in C++,
> >the need for special C++ "discipline" in the python code goes
> >away. Weeks are slashed from the schedule, and the program is
> >more maintainable.
> >
> >Another nice advantage is that the python programmer gets to ask
> >for a raise, and has excellent job security!
>
Raise (hopefully) for completing projects massively under time and budget.
Security ... because they will want to hold onto someone so good.
Unfortunately, this will only work for 1 or 2 projects ... after that they
will *expect* you to bring everything in under time and budget ... but by
then the time and budget is massively reduced because of the great results
you've brought in ...
:)
Tim Delaney
Roman Suzi
But, for example, C++ has 3 categories of object attributes. Do you mark
them somehow in Python, group them to be later marked as public,
protected, private? And there are lot's of details like this one.
Related topic is UML with Python. Does UML has everything to reflect
Python OO model or does it need to add features?
(Or maybe in order to interoperate, there is a need not to use some
of Python features).
And if in order to interoperate with less expressive languages/systems,
how to keep Python pythonic and not fall back to some standard universal
subset, found in many programming languages.
Sincerely yours, Roman Suzi
--
\_ Russia \_ Karelia \_ Petrozavodsk \_ r...@onego.ru \_
\_ Monday, June 03, 2002 \_ Powered by Linux RedHat 7.2 \_
\_ "Bugs are Sons of Glitches!" \_
Roman Suzi
>> prototype certain design? Developing in C++ looks so unnecessary hard
>> after things were done in Python...
>> Or, it may be put this way: what discipline a Python programmer must
>> obey to allow it's prototype to be conveniently rewriten in C++?
>> The above thoughts aren't probably well-formed. But I hope
>> my concern is understood.
>>
>>
>> Sincerely yours, Roman Suzi
>
>I agree with what you are saying. Here's my approach :-)
>
>0. Write a project schedule for management; something like this:
> 1. Prototype in python
> 2. Convert to C++
>1. Prototype in python
>2. Give a nice demo, and convince management to skip step 2
>3. Re-implement a few cpu intensive classes in C++
Interesting ;-)
>Since most of the code never /actually/ gets rewritten in C++,
>the need for special C++ "discipline" in the python code goes
>away. Weeks are slashed from the schedule, and the program is
>more maintainable.
>
>Another nice advantage is that the python programmer gets to ask
>for a raise, and has excellent job security!
...because only he knows the magic powers of Python?
>There may be a few oddball examples of projects that actually
>need to end up written in C++ after prototyping in python, but
>for the most part, the most common reason to target C++ is to
>alleviate fear of the unknown. (Hmm, is this also why people,
>(including myself), still buy from Microsoft? :-)
Fear of unknown? That is why I DO NOT buy from Microsoft ;-)
>- Ken Seehof
Phlip
>> 1. Prototype in python
>> 2. Convert to C++
>>1. Prototype in python
>>2. Give a nice demo, and convince management to skip step 2
>>3. Re-implement a few cpu intensive classes in C++
http://www.c2.com/cgi/wiki?AlternateHardAndSoftLayers
This means that after prototyping in Python one /incrementally/ refactors
elements into C++ (hopefully via the Boost Python Library). Of course the
speed elements go into C++, as do the elements that bind with legacy C++
stuff.
It's what the Python community already does. We don't crack JPEG files in
Python; we just call into a C layer like imlib, via a binding layer.
--
Phlip
http://www.greencheese.org/EvolutionaryPsychology
-- Now collecting votes for a new group:
news:alt.flame.moderated --
Dean Goodmanson
> > 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
Greg Ewing
>
> Unfortunately, this will only work for 1 or 2 projects ... after that they
> will *expect* you to bring everything in under time and budget ...
So, don't tell them it's finished until just before the
deadline... and find something plausible-sounding to
spend the extra money on... :-)
--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
Delaney, Timothy
>
> "Delaney, Timothy" wrote:
> >
> > Unfortunately, this will only work for 1 or 2 projects ...
> after that they
> > will *expect* you to bring everything in under time and budget ...
>
> So, don't tell them it's finished until just before the
> deadline... and find something plausible-sounding to
> spend the extra money on... :-)
Hmm ... so *that's* how I get the raise that was being talked about ... ;)
Sometimes, there's such a thing as being too honest ...
Tim Delaney
Andrae Muys
> 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++.
>
One thing I'm very interested in is knowing if anyone has any
experience with Python/Jython -> Java? Many managers are now firm
believers in the gospel of Scott, but selling them Python as
prototyping support for their new favourite seems feasible.
Andrae Muys
Stephen J. Turnbull
Timothy> Unfortunately, this will only work for 1 or 2 projects
Timothy> ... after that they will *expect* you to bring everything
Timothy> in under time and budget ... but by then the time and
Timothy> budget is massively reduced because of the great results
Timothy> you've brought in ...
Of course, if your managers figure that out in only one or two
projects, you take your raise in stock. If they're dumb enough not to
understand that the third project is a little late and over budget
because they've underestimated the needs, you take a short position
... and project 4 is massively over budget because you spent all the
time working on your resume.<wink>
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
Geoff Gerrietts
> On Sat, 1 Jun 2002, Sean 'Shaleh' Perry wrote:
>
> Related topic is UML with Python. Does UML has everything to reflect
> Python OO model or does it need to add features?
> (Or maybe in order to interoperate, there is a need not to use some
> of Python features).
With UML, I generally find that it has TOO MANY features. If I use
Visio, or Rose, or even the lovely pyut announced a few months ago on
this very list, they'll ask for information about attribute and method
visibility, data types, etc.
Since Python doesn't care about most of this stuff, modelling it is
only useful if you expect to port the code later. And I prefer not to
plan for an unfortunate event. ;)
> And if in order to interoperate with less expressive
> languages/systems, how to keep Python pythonic and not fall back to
> some standard universal subset, found in many programming languages.
Certainly you could use UML and thorough documentation as a hedge
against relying too heavily on Python's dynamic nature. A startling
percentage of the things we take for granted in python can actually be
expressed similarly in other languages, though -- it just takes more
work, more infrastructure, and a few more lines of code.
I've written code with the thought that I'd eventually rewrite it in
another language, and I shared many of your concerns about how well
ideas would "port".
For the most part, I find myself doing one of two things: either
writing the other (generally Java) language's idioms (like Singleton,
like stateless classes) in Python when it's not too inconvenient, or,
when it is, just writing it off as "the burden of porting".
For the most part, the really "interesting" parts of your system are
going to port relatively cleanly, because you're doing calculations
and computations. It's the boilerplate crap that you can skip over
pretty effortlessly, and that's going to be the irritation of porting
anyway.
You can, of course, take special steps to avoid hard-to-port code.
That's where you spend time writing foreign idioms into your Python
code. How much time you waste doing that will largely depend on how
quickly you need the "convert to another language" step to go.
--G.
--
Geoff Gerrietts "I am always doing that which I can not do,
<geoff at gerrietts net> in order that I may learn how to do it."
http://www.gerrietts.net --Pablo Picasso
Roman Suzi
Hmmm... Computations could be different.
For example, in python I can use a couple of .strip/.split/.join
things and get the needed format parsed.
In other languages to do the same I need to write it again and
again or find some lib to do it for me.
Or, sometimes I prefer to put things like (in one breath,
without errors):
data = """parse|me|heavy
1|2|3
2|3|4
"""
data = map(lambda x: x.split("|"), data.strip().split("\n"))
and then have fun with a "burden of porting", rewriting
the above example in C...
Or maybe I became too lazy?
>You can, of course, take special steps to avoid hard-to-port code.
What are these? Not to use Python features at all and write crap like:
data[0][0] = "parse";
data[0][1] = "me";
data[0][2] = "heavy";
....
- often found in VB programs?
My examples are data-oriented, but logic-oriented ones are
no less funny.
Well, maybe I could automate the above with as little as:
i = 0
for d in data:
j = 0
for dd in d:
print """data[%(i)s][%(j)s] = "%(dd)s";""" % vars()
# ;-)
>That's where you spend time writing foreign idioms into your Python
>code. How much time you waste doing that will largely depend on how
>quickly you need the "convert to another language" step to go.
Anyway, thank you for your ideas, Geoff!
>--G.
>
>
Sincerely yours, Roman Suzi
--
\_ Russia \_ Karelia \_ Petrozavodsk \_ r...@onego.ru \_
\_ Tuesday, June 04, 2002 \_ Powered by Linux RedHat 7.2 \_
\_ "Shin: A device for finding furniture in the dark." \_
Martin Sjögren
> Since Python doesn't care about most of this stuff, modelling it is
> only useful if you expect to port the code later. And I prefer not to
> plan for an unfortunate event. ;)
I still it is good to think in terms of 'public' and 'private', even
though the names are badly chosen. I prefer 'interface' and
'implementation'. If you don't decide which of your class members are to
be part of the interface and which are implementation-specific, I feel
that is a good way to shoot yourself in the foot.
Martin
--
Martin Sjögren
mar...@strakt.com ICQ : 41245059
Phone: +46 (0)31 7710870 Cell: +46 (0)739 169191
GPG key: http://www.strakt.com/~martin/gpg.html
Roman Suzi
(I oversaw this post and I feel I need to answer it)
> Ken Seehof <kse...@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:r...@onego.ru -
Eric Brunel
[snip]
> Since Python doesn't care about most of this stuff, modelling it is
> only useful if you expect to port the code later.
Eeeer, maybe I'll start yet another flame war here, but I strongly disagree
with this statement! Modelling is *always* useful if your application isn't
a "quick and dirty" one, is significantly large and/or if it may have
several versions and/or several persons that will work on it. UML diagrams
are not just another representation of the code: it allows the developers
to take a step back and look at the whole picture instead of just their
little part of the code. If you have several cooperating classes, it also
allows to visually design these cooperations, instead of having to look
everywhere in the code to see where a particular class is used (and also
*if* it's still used at all...). In fact, I find UML design particularly
useful on large/medium Python applications, precisely *because* of Python's
dynamic features and lack of strong typing. If you want your code to be
readable by other people than just yourself, and maybe at a time where
you'll not even be around anymore, a good documentation of the code is
really needed...
Whether UML is well-suited for documenting Python applications is of course
debatable. I personaly find it quite convenient:
- on one hand, it counter-balances the "fuzzy" part of Python (no
declarations, everything is dynamic) by allowing to actually declare
everything. Let's be honest here: in a significantly large application, a
big part of the code make assumptions on the objects it handles, and may
benefit from strong typing. Not having to declare everything's type is
quite handy, but may in the end make the code unreadable if you do not have
something that tells you what is needed on the objects you manipulate...
- on the other hand, UML is quite open and may also allows to document
"fuzzy" features, or things really specific to a language like Python. For
example, UML doesn't know anything about Python dictionaries, since
dictionaries are quite often not natively supported by other languages. But
if you know your target language will be Python, you may just use a
specific "custom" type like "dict<key type, value type>" in your UML spec.
Of course, if the tool you use to design your UML diagrams is too
restrictive, it may report an error on this kind of declaration, but
well..., no big deal... The whole purpose of UML diagrams is documentation,
not making correct diagrams for Rational Rose or whatever other tool...
Of course, many features of UML tools cannot be used at all with Python:
semantics checking may be disturbed by your custom Python types, and I
don't know a single UML tool that can generate Python code (if anybody
knows one, please let me know!). But again: no big deal... When you'll get
back to your code in a few months or years, you'll be really glad to have
your UML spec at hand to understand how your few dozens classes speak to
each other...
--
- Eric Brunel <eric....@pragmadev.com> -
PragmaDev : Real Time Software Development Tools - http://www.pragmadev.com
Kragen Sitaker
> With UML, I generally find that it has TOO MANY features. If I use
> Visio, or Rose, or even the lovely pyut announced a few months ago on
> this very list, they'll ask for information about attribute and method
> visibility, data types, etc.
>
> Since Python doesn't care about most of this stuff, modelling it is
> only useful if you expect to port the code later. And I prefer not to
> plan for an unfortunate event. ;)
Well, maybe I'm polluted by my previous experience with other
sort-of-OO languages like C++, but I still include method visibility
and data types in my Python designs.
Attributes are never visible (although that will probably change when
I start using 2.2, because visible attributes will cease to cost
flexibility), most methods are visible, and occasionally I'll add some
private methods, usually named with a leading underscore.
WRT data typing, I usually try to know what kind of thing is in
particular attributes of my classes. The answer might be "a number",
"a sequence", "a sequence of numbers", "a mapping from strings to
sequences of (string, number) tuples", but I try to keep a clear idea
in mind of what it is.
Python makes it very easy to change my mind about all of these things.