[Tutor] Verifying My Troublesome Linkage Claim between Python and Win7

Wayne Watson sierra_mtnview at sbcglobal.net
Sat Feb 27 19:30:49 CET 2010

Ok, I'm back after a three day trip. You are correct about the use of 
pronouns and a few misplaced words. I should have reread what I wrote. I 
had described this in better detail elsewhere, and followed that 
description with the request here probably thinking back to it.  I think 
I was getting a bit weary of trying to find an answer. Try t;his.



data and dset files have the same record formats. track1.py was copied 
into  Folder2 with ctrl-c + ctrl-v. When I run track1.py from folder1,  
it clearly has examined the data.txt  files. If I run the copy of 
track1.py in folder2, it clearly operates on folder1 (one) data.txt 
files. This should not be.

If I look at  the  properties of track1.py in folder2  (two), it  is  
pointing back to the program in folder1 (one).

I do not believe I've experienced this sort of linkage in any WinOS 
before. I believed I confirmed that the same behavior occurs using cmd 

I'll now  head for Alan's reply.

On 2/23/2010 5:35 PM, Dave Angel wrote:
> Wayne Watson wrote:
>> A few days ago I posted a message titled ""Two" Card Monty. The 
>> problem I mentioned looks legitimate, and remains puzzling. I've 
>> probed this in a newsgroup, and no one has an explanation that fits.
>> My claim is that if one creates a program in a folder that reads a 
>> file in the folder it ... then copies it to another folder, it will 
>> read  the data file in the first folder, and not a changed file in 
>> the new folder. I'd appreciate it if some w7 users could try the 
>> program below, and let me know what they find.  I'm using IDLE in 
>> Win7 with Py 2.5.
>> My experience is that if one checks the properties of the copied 
>> file, it will point to the original py file and execute it and not 
>> the copy. If win7 is the culprit, I would think this is a somewhat  
>> serious problem. It may be the sample program is not representative 
>> of the larger program that has me stuck. If necessary I can provide 
>> it. It uses common modules. (Could this be something like the 
>> namespace usage of variables that share a common value?)
>> # Test program. Examine strange link in Python under Win7
>> # when copying py file to another folder.
>> # Call the program vefifywin7.py
>> # To verify my situation use IDLE, save and run this program there.
>> # Put this program into a folder along with a data file
>> # called verify.txt. Create a single text line with a few characters 
>> in it
>> # Run this program and note the output
>> # Copy the program and txt file to another folder
>> # Change the contents of the txt file
>> # Run it again, and see if the output is the same as in the other folder
>> track_file = open("verify.txt")
>> aline = track_file.readline();
>> print aline
>> track_file.close()
> I find your English is very confusing.  Instead of using so many 
> pronouns with confusing antecedents, try being explicit.
> >My claim is that if one creates a program in a folder that reads a 
> file in the folder
> Why not say that you created a program and a data file in the same 
> folder, and had the program read the data file?
> >...in the folder it and then copies it to another folder
> That first 'it' makes no sense, and the second 'it' probably is meant 
> to be "them".  And who is it that does this copying?  And using what 
> method?
> > ... it will read  the data file in the first folder
> Who will read the data file?  The first program, the second, or maybe 
> the operator?
> About now, I have to give up.  I'm guessing that the last four lines 
> of your message were intended to be the entire program, and that that 
> same program is stored in two different folders, along with data files 
> having the same name but different first lines.  When you run one of 
> these programs it prints the wrong version of the line.
> You have lots of variables here, Python version, program contents, 
> Idle, Windows version.  Windows 7 doesn't do any mysterious "linking," 
> so I'd stop making that your working hypothesis.  Your problem is most 
> likely the value of current directory ( os.getcwd() ).  And that's set 
> according to at least three different rules, depending on what program 
> launches Python.  If you insist on using Idle to launch it, then 
> you'll have to convince someone who uses Idle to tell you its 
> quirks.   Most likely it has a separate menu for the starting 
> directory than for the script name & location.  But if you're willing 
> to use the command line, then I could probably help, once you get a 
> clear statement of the problem.  By default, CMD.EXE uses the current 
> directory as part of its prompt, and that's the current directory 
> Python will start in.
> But the first things to do are probably to print out the value of  
> os.getcwd(), and to add a slightly different print in each version of 
> the program so you know which one is running.
> Incidentally, I'd avoid ever opening a data file in "the current 
> directory."  If I felt it important to use the current directory as an 
> implied parameter to the program, I'd save it in a string, and build 
> the full path to the desired file using  os.path.join() or equivalent.
> DaveA

             "There is nothing so annoying as to have two people
              talking when you're busy interrupting." -- Mark Twain

More information about the Tutor mailing list