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

Dave Angel davea at ieee.org
Sat Feb 27 21:38:58 CET 2010



Wayne Watson wrote:
> 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.
>
>
> Folder1
>    track1.py
>   data1.txt
>   data2.txt
>   data3.txt
>
> Folder2
>    track1.py
>    dset1.txt
>    dset2.txt
>    ...
>    dset8.txt
>
So how do you know this is the structure?  If there really are shortcuts 
or symbol links, why aren't you showing them?   Did you do a DIR from 
the command line, to see what's there?  Or are you looking in Explorer, 
which doesn't even show file extensions by default, and just guessing 
what's where ?

> data and dset files have the same record formats. track1.py was copied 
> into  Folder2 with ctrl-c + ctrl-v. 

Those keys don't work from a command prompt.  From there, you'd use COPY 
or something similar.  So I have to guess you were in an Explorer 
window, pointing to Folder 1, and you selected the python file, and 
pressed Ctrl-C.  Then you navigated to Folder 2, and pressed Ctrl-V.  If 
you did,  Windows 7 wouldn't have created any kind of special file, any 
more than earlier ones did.  Chances are you actually did something 
else.  For example, you might have used a right-click drag, and answered 
"create shortcut" when it asked what you wanted to do.  Or perhaps you 
did drag/drop with some ctrl-or alt-key modifier.

Anyway, you need to be more explicit about what you did.  If you had 
used a command prompt, you could at least have pasted the things you 
tried directly to your message, so we wouldn't have so much guessing to do.
> When I run track1.py from folder1,  it clearly has examined the 
> data.txt  files. 
And how are you running track1.py ?  And how do you really know that's 
what ran?  The code you posted would display a string, then the window 
would immediately go away, so you couldn't read it anyway.
> 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).
Exactly what do you mean by "pointing back" ?  If you're getting icons 
in your Explorer view, is there a little arrow in the corner?  When you 
did the properties, did you see a tab labeled "shortcut" ?
>
>
> 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 
> prompt.
>
Shortcuts have been in Windows for at least 20 years.  But you still 
haven't given enough clues about what you're doing.
> 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
>>
>>
>


More information about the Tutor mailing list