Re: [Tutor] Verifying My Troublesome Linkage Claim between Python and Win7
Wayne Watson sierra_mtnv...@sbcglobal.net wrote incoherency. For what it's worth, and that's about zero, I'm working with my old XP and W7 machine's keyboards, mice and monitors side-by-side. I have several times found my self using the wrong device. In that situation I find it useful to make the old environment as hostile as possible. So I'd make the resolution on the XP box something like 800x600 and set the wallpaper to a garish colour like red. That way I never mistake which machine I'm on! FWIW I do the same with the root account on Unix boxes... That makes sure I spend as little time as possible in the environment that I don't want to stay in. HTH, -- Alan Gauld Author of the Learn to Program web site http://www.alan-g.me.uk/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Verifying My Troublesome Linkage Claim between Python and Win7
Wayne Watson wrote: snip You tell us to try this and give a folder structure: Folder1 track1.py data1.txt data2.txt data3.txt Folder2 track1.py dset1.txt dset2.txt ... dset8.txt snip Maybe one simple test at a time will get better responses. Since you wouldn't tell me what tabs you saw in Explorer when you did properties, maybe you'll tell me what you see in CMD. Go to a cmd prompt (DOS prompt), change to the Folder2 directory, and type dir. paste that result, all of it, into a message. I suspect you'll see that you don't have track1.py there at all, but track1.py.lnk If so, that's a shortcut. The only relevant change in Win7 that I know of is that Explorer shows shortcuts as link rather than shortcut. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Verifying My Troublesome Linkage Claim between Python and Win7
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 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 prompt. 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
Re: [Tutor] Verifying My Troublesome Linkage Claim between Python and Win7
I just referenced Alan to my response to you, and included this statement. Once you've both read the first reply to you and this, then you should both be in synch with where I'm at. To Alan=== Oh, I also changed the name of folder1 in the reply to Dave to see what would happen with the copied py file in folder2 upon execution. It couldn't find the py file in folder1. -- There is nothing so annoying as to have two people talking when you're busy interrupting. -- Mark Twain ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Verifying My Troublesome Linkage Claim between Python and Win7
On Sun, 28 Feb 2010 05:30:49 am 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 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. Without seeing the code in track1.py, we cannot judge whether it should be or not. I can think of lots of reasons why it should be. For example: if you have hard-coded the path to Folder1 if you call os.chdir(Folder1) if you have changed the PATH so that Folder1 gets searched before the current directory then the behaviour you describe theoretically could happen. How are you calling track1.py? Do you do this? cd Folder2 python track1.py What if you change the second line to: python ./track1.py Are you perhaps using this? python -m track1 If you change the name of the copy from track1.py to copy_of_track1.py, and then call this: python copy_of_track1.py how does the behaviour change? If I look at the properties of track1.py in folder2 (two), it is pointing back to the program in folder1 (one). What? Pointing back, as in a Shortcut? Or a symlink? If you've created a shortcut instead of a copy, I'm not surprised you are executing it in the wrong folder. That's what shortcuts do. -- Steven D'Aprano ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Verifying My Troublesome Linkage Claim between Python and Win7
See below.
On 2/27/2010 10:58 AM, Steven D'Aprano wrote:
On Sun, 28 Feb 2010 05:30:49 am 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
this.
Folder1
track1.py
data1.txt
data2.txt
data3.txt
Folder2
track1.py
dset1.txt
dset2.txt
...
dset8.txt
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.
Without seeing the code in track1.py, we cannot judge whether it should
be or not. I can think of lots of reasons why it should be. For
example:
I'll attach the code to this. However, I haven't had the best of luck
getting attachments posted. Frankly, I think it's better to try the
sample program I provided at the top of the thread. If you are not using
Win7, I don't think this is going to work well, but maybe you'll see
something that's a no-no in any OS. I have several data files, if anyone
wants to go that far. I can supply a data file if necessary. Note this
program is still in development. In fact, I was going to pull the debug
wtw statements and wrap it all up when this problem occurred.
if you have hard-coded the path to Folder1
if you call os.chdir(Folder1)
Not to my knowledge. I just assume that the program will read the txt
files in alpha order in the same folder as the program.
if you have changed the PATH so that Folder1 gets searched before the
current directory
then the behaviour you describe theoretically could happen.
How are you calling track1.py? Do you do this?
cd Folder2
python track1.py
Yes, I believe I've tried that.
What if you change the second line to:
python ./track1.py
Are you perhaps using this?
python -m track1
Don't even know what it means.
If you change the name of the copy from track1.py to copy_of_track1.py,
and then call this:
python copy_of_track1.py
how does the behaviour change?
I'll try it later. I probably have tried it already. See my point
comments below. If Properties doesn't change, changing the name isn't
going to work.
If I look at the properties of track1.py in folder2 (two), it is
pointing back to the program in folder1 (one).
What? Pointing back, as in a Shortcut? Or a symlink?
Aren't symlinks Linux world? I know nothing about them. Windows7
Properties of track1.py in folder 2 (two) show the py file is really in
folder1.
If you've created a shortcut instead of a copy, I'm not surprised you
are executing it in the wrong folder. That's what shortcuts do.
If I've created a shortcut, it wasn't by design. Ctrl-c to ctrl-v most
likely.
--
There is nothing so annoying as to have two people
talking when you're busy interrupting. -- Mark Twain
# Generates summary reports on description txt files in present folder
# There are three output files, A, B and C.
# A produces a report with titles and column descriptions along with event data
# B only produces event data, no titles; otherwise, same as A
# C produces a report with titles and amplitude stats; otherwise same as A
# Things to do
# Re-examine magnitude philosophy on segments and for first 30 seconds.
# print DST year via dictionary entry
# sentuser txt (track data) contents on each line
# 1. Frame count relative to the trigger time. Negative values are before
trigger. Positive values are after trigger.
# 2. Number of pixels that are above threshold.
# 3. Amplitude. Basically, the sum of all pixels above threshold.
# 4. X coordinate of the event centroid, in pixels.
# 5. Y coordinate of the event centroid, in pixels.
#
# There is a header line, which is followed by an empty line
# Note that some of the functions here are not used here They are
# part of a class, and as such are perfectly acceptable Python's reuseability
# philosophy. They produce statistics that may be needed in the future,
# particularly the segment calcs. See the CollectTrkData class.
import sys, os, glob
import string
from numpy import *
from datetime import datetime, timedelta
import time
from scipy import stats as stats # scoreatpercentile
# DST for several years from
# Naval Obs. http://aa.usno.navy.mil/faq/docs/daylight_time.php
DST_dict = { # West coast, 8 hours from Greenwich for PST (Pacific States)
2007:(2007/03/11 02:00:00, 2007/11/04 02:00:00),
2008:(2008/03/09 02:00:00, 2008/11/02 02:00:00),
2009:(2009/03/08 02:00:00, 2009/11/01 02:00:00),
2010:(2010/03/14
Re: [Tutor] Verifying My Troublesome Linkage Claim between Python and Win7
On 2/27/2010 5:24 PM, Steven D'Aprano wrote: Hello Wayne, I sympathise with your problem, but please understand you are not making it easy for us when you give us incoherent information. I hope the coherency has improved recently. :-) I think if you saw the cramped quarters I'm in that you might understand my supposed incoherency. For what it's worth, and that's about zero, I'm working with my old XP and W7 machine's keyboards, mice and monitors side-by-side. I have several times found my self using the wrong device. I'm steadily moving from programs and data from one to another. This weekend when I get a printer cable, the XP machine will be relegated to a distant table. You tell us to try this and give a folder structure: Folder1 track1.py data1.txt data2.txt data3.txt Folder2 track1.py dset1.txt dset2.txt ... dset8.txt but then when you send a copy of the actual code you are running, it is called ReportingToolAwww.py and it is 417 lines long. What happened to track1.py? What is in that? Does track1.py reproduce the fault? Yes, it's a lot easier to type track than the above. I invented fictitious names for the above to simplify it all. The program does indeed work on track data for meteor trails. There are five possible faults: 1 A problem in your Python code. 2 A serious bug in Python itself. 3 A serious bug in Windows file system. 4 Disk corruption making Windows confused. 5 A PEBCAK problem. I'd vote for a W7 problem. I think I mentioned that W7 will not even allow me to find all files in a folder with track in them. It's possible the new filter concept for files is at work. I can confirm that ReportingToolAwww.py doesn't seem to contain any funny path manipulations that would cause the problem: it simply calls open on relative path names, which will open files in the current directory. The problem does NOT appear to be in your Python code. Good. A serious bug in either Python or Windows is very unlikely. Not impossible, but unless somebody else reports that they too have seen the fault, we can dismiss them. See above about W7. Disk corruption is possible. If all else fails, you can run the Windows disk utility to see if it finds anything. Beats me. But the most likely cause of the fault is that you aren't running what you think you are running. When you say: If I've created a shortcut, it wasn't by design. Ctrl-c to ctrl-v most likely. Most likely? Meaning you're not sure? Meaning I agree with you that it was not a use of ctrl-c/v. I offered the other only possibilities I know of. That's for programs likeWord. Given that you are talking about the Properties window talking about pointing to things, I think it is very likely that in fact you have created a shortcut, or a symlink, and when you think you are running a copy in Folder2 you are actually running a shortcut to Folder1. That would *exactly* explain the problem you are experiencing. Please take a screenshot of the Properties window showing the pointing to stuff. I think you will find that track1.py in Folder2 is a shortcut back to track1.py in Folder1. OK, I'll do that with SnagIt, and attach it. If it's too big, it will not make it on the list, but will make it to you.Geeze, I can't even do that. I had contacted HP tech support (1 year of free support), and went through this with a tech guy week ago. I gave him control of the machine, and he started messing with the py file.I stopped him before he changed anything, but copied the file somewhere, and renamed it, so he could do what he thought needed to be done. The link points to itself. I'm afraid after a week of dealing with this the trail is dead. Chalk it up to a mistake on my part if you will. I'm done. If somehow this magically revives itself in the next few days, I'll respond. It's time to move this program ahead to completion. (For the record, Windows does in fact have symlinks, as well as hard links and a third type of link called junction points. They are undersupported by Explorer, and so people hardly every use them. Most people don't even know they exist, even though some of them go back all the way to Windows NT. But as far as I can tell, there is no way for you to have created a symlink from Explorer.) So noted. The last time I had anything to do with the more esoteric links is a decade ago when I worked with Linux. -- There is nothing so annoying as to have two people talking when you're busy interrupting. -- Mark Twain ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Verifying My Troublesome Linkage Claim between Python and Win7
Hang in there. My story about HP tech support took me a bit off course. I think I can provide a meaningful description from the stand point of the properties of each py file. I want to look at this carefully. -- There is nothing so annoying as to have two people talking when you're busy interrupting. -- Mark Twain ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] Verifying My Troublesome Linkage Claim between Python and Win7
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 and 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() -- There is nothing so annoying as to have two people talking when you're busy interrupting. -- Mark Twain ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Verifying My Troublesome Linkage Claim between Python and Win7
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 and 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 ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
