prototyping good OOdesign in Python?

[Roman Suzi]

On Wed, 5 Jun 2002, Geoff Gerrietts wrote:

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

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 \_ rnd at onego.ru \_
\_ Tuesday, June 04, 2002 \_ Powered by Linux RedHat 7.2 \_
\_ "Shin: A device for finding furniture in the dark." \_