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

[Dave Angel]

(Multiple people on this thread have been quoting earlier people without 
keeping the attribution lines  (e.g.   xxxx yyy wrote: )
    so I'm not sure who said what any more.  I recognize my own words, 
of course, but for anybody else, your guess is
    better than mine)

Stephen Nelson-Smith wrote:
> 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.
>
>   
The string to use is "r+b"   The  r  says you're going to read it.  The 
+ says you're also going to write it.  And the  b  says you don't want 
any character translation going on.  Text files should only be written 
in one direction, or appended, but not updated in-place, except in very 
specific circumstances.

If you're both reading and writing, you need to do a seek() in between.  
So you'll be doing two seeks per loop. And since each line is a variable 
size, you'd have to keep track of that size.  And if you were on a 
Windows machine, the size of the string you see may not match the size 
on the file ( 0d0a becomes 0a when reading a text file).  Finally, even 
if you get all that right, the specific example is trying to replace 
lines with new lines of a different length.  Not in this world.
>> 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?
>
>   
Exactly.  In that short fragment, there are three meanings for the name 
file.  It's a built-in type until the first time you change it.  Then it 
becomes a string.  And after the with statement it becomes a file 
object.  If you had to check its type, that would be quite difficult.  
And if you needed its name, you've clobbered it.

>>> 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?
>
>   
I'm not sure where these "settings" values come from.  But if these are 
arbitrary command lines, it's plausible that one command works on a file 
whose name looks like one of the other commands.   I'd feel better with 
something like "startswith()"  instead of "in" .  But just as a general 
precaution, I'd put a break in the for loop whenever one of them matches
>> 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?
>
>   
As it stands, it only writes the line when it needs to change.  But that 
implies that you've been keeping track of sizes so you can put a seek 
before and after the line, and of course that the size doesn't change.  
Since none of these is true (or practical), my comment was assuming that 
you're using a different "output" file.  So you need to write every 
line, not just the ones that change.
>>  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.
>
>   

With inputfile, you'll basically copy the file from the supplied 
iterator to stdout (probably using print), doing any conversions on the 
line as you go.

DaveA