Elementary string-parsing

[Odysseus]

In article <60osssF1ro06iU5 at mid.uni-berlin.de>,
 Marc 'BlackJack' Rintsch <bj_666 at gmx.net> wrote:

<snip>

> The term "global" usually means "module global" in Python.

Because they're like the objects obtained from "import"?

> [T]he functions depend on some magic data coming from "nowhere" and 
> it's much harder to follow the data flow in a program.  If you work 
> with globals you can't be sure what the following will print:
> 
> def spam():
>     global x
>     x = 42
>     beep()
>     print x
> 
> `beep()` might change `x` or any function called by `beep()` and so on. 

I think I get the general point, but couldn't "beep()" get at "x" even 
without the "global" statement, since they're both in "spam()"?

It seems natural to me to give the most important objects in a program 
persistent names: I guess this something of a 'security blanket' I need 
to wean myself from. I can appreciate the benefits of 
context-independence when it comes to reusing code.

> Another issue is testing.  If you rely on global names it's harder to test
> individual functions. [...]
> 
> In programs without such global names you see quite clearly in the
> ``def`` line what the function expects as input.

Good points, although thorough commenting can go a long way to help on 
both counts. In theory, at least ...

<snip>

> It's easy to "enforce" if you have minimal code on the module level.  The
> usual idiom is:
> 
> def main():
>     # Main program comes here.
> 
> if __name__ == '__main__':
>     main()
> 
> Then main is called when the script is called as program, but not called if
> you just import the script as module.  For example to test functions or to
> reuse the code from other scripts.

I'm using "if __name__ == 'main'" now, but only for test inputs (which 
will eventually be read from a config file or passed by the calling 
script -- or something). I hadn't thought of putting code that actually 
does something there. As for writing modules, that's way beyond where I 
want to go at this point: I don't know any C and am not sure I would 
want to ...
 
[consolidating]

In article <60ountF1s5jpaU1 at mid.uni-berlin.de>,
 Marc 'BlackJack' Rintsch <bj_666 at gmx.net> wrote:

<snip>

> Then you can either pass in `found` as argument instead of creating it
> here, or you collect the passes in the calling code with the `update()`
> method of `dict`.  Something like this:
> 
> found = dict()
> for pass in passes:
>     # ...
>     found.update(extract_data(names, na, cells))

Cool. I'll have to read more about dictionary methods.

<snip>

> >>         assert name.startswith('Name: ')

> It checks if `name` really starts with 'Name: '.  This way I turned the
> comment into code that checks the assertion in the comment.

Good idea to check, although this is actually only one of many 
assumptions I make about the data -- but what happens if the assertion 
fails? The program stops and the interpreter reports an AssertionError 
on line whatever?

<snip>

> [I]f you can make the source simpler and easier to understand by 
> using the `index()` method, use a list.  :-)

Understood; thanks for all the tips.

-- 
Odysseus