[Tutor] proxy switcher - was Re: I love python / you guys :)

[Stephen Nelson-Smith]

Evening,
> Yes, you can, but not this way.  I'm guessing the op was changing his mind
> back and forth, between having two files, one for reading and one for
> writing, and trying to do it in place.  The code does neither/both.

Well, just neither I think!  I didn't check if 'rw' was possible.  My
plan was to read the file and write to the same file as the change was
made, to avoid having to use temporary files and os.move.  But I
wasn't near a machine with python on it, so it was untested.

> Take a look at fileinput.FileInput()  with the inplace option.  It makes it
> convenient to update text files "in place" by handling all the temp file
> copying and such.  It even handles iterating through the list of files.

Will definitely look into that.

> Good point about 'file' as its a built-in name.  If the code ever has to use
> the std meaning, you have a problem.  Worse, it's unreadable as is.

Thanks for that hint.  In what way is it unreadable?  Because the
intent is not clear because of the ambiguity of the name?

>> Also, you didn't define 'output' anywhere.  Is this an implicit
>> declaration

No, just a dumb mistake.

> Another potential  bug with the code is if more than one "setting" could
> appear in a line. It would change the line for an odd number, and not for an
> even number of matches.

Not sure I follow that.  From the OPs description, it appeared he
would be entering these lines in.  I figured it was safe to trust the
OP not to put in duplicate data.  Maybe defensively I should check for
it anyway?

> Also, the nesting of output.write() is wrong, because file position isn't
> preserved, and random access in a text file isn't a good idea anyway.

Could you expand on this?

>  But
> there's not much point in debugging that till the OP decides how he's going
> to handle the updates, via new files and copying or renaming, or via
> inputfile.

I'll look up inputfile, and try again :)

S.