Suggestions for good programming practices?

[Roman Suzi]

On Mon, 24 Jun 2002, David LeBlanc wrote:

>Grrrr!
>
>Look at it this way:
>
>	a,b,c = func()
>
>	abc = func()
>	a = abc[0]
>	b = abc[1]
>	c = abc[2]
>
>Which would you rather write? In C or C++ you have to use an analog of the
>second way since the first way isn't an option. I _like_ this behavior of
>Python.
>
>It's a piddling point as to how Python returns the info - they come to rest
>in discrete variables, not as elements of one aggregate variable. The
>original point was about the flexibility of Python not some technical
>hair-splitting about what Python might put on the stack.


The 'a,b,c = func()'-style is good as far as there will be 
no soon change to the number of variables.

I'd not advice using this style as I fight it now in my own 
old scripts...

Now I am using dicts or instances to hold values:
it gives context information:

       abc = func()
       ... use abc["first"]
       abc["second"] ...
       ... abc["third"]

or (in the less trivial cases):

       abc = func()
       ... use abc.first
       abc.second ...
       ... abc.third

Or I am using 'constants' to access return:

       FIRST,SECOND,THIRD = range(3)

       ...

       abc = func()
       ... use abc[FIRST]
       abc[SECOND] ...
       ... abc[THIRD]


- all these allow variable number of returned values thus
keeping compatibility. (for example, I can access old
and new logs by the same code).

Well, to be honest, I am also using this approach:


a,b,c,d,e = (func()+ (None,)*2)[:5]

when originally there were 3 vars and now I sometimes get
3, sometimes 5.
but it is not very nice...

- those my examples aren't probably good programming practices,
but they allow not to loose context when flexibility is needed.

>David LeBlanc
>Seattle, WA USA

Sincerely yours, Roman Suzi
-- 
rnd at onego.ru =\= My AI powered by Linux RedHat 7.2