[Tutor] Verifying My Troublesome Linkage Claim between Python and Win7
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
> 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
> > ... 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.
"There is nothing so annoying as to have two people
talking when you're busy interrupting." -- Mark Twain
More information about the Tutor