prototyping good OOdesign in Python?

[Geoff Gerrietts]

Quoting Roman Suzi (rnd at onego.ru):
> 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