Re: OT: Meaning of "monkey"
I prefer to think of myself as a code-ape - I look down on code-monkeys. -- http://mail.python.org/mailman/listinfo/python-list
Re: python to exe
Mark Lawrence wrote: I'm certain that members of the Guinea Pig Club might have something to say on that one, see :- http://en.wikipedia.org/wiki/Guinea_Pig_Club You mean, something like: "That's not funny"? -- http://mail.python.org/mailman/listinfo/python-list
Re: python to exe
Steven D'Aprano wrote: As the old proverb goes: give a man a fish, and you feed him for a day. Teach him how to fish, and he has food forever. I like this version: Light a man a fire, and you keep him warm for hours. Set a man on fire, and you keep him warm for the rest of his life. ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: running a program on many processors
Paweł Banyś wrote: ... How can it be achieved? Very carefully. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyQt4.7 and PyQwt5.2.0
Gib Bogle wrote: I installed the latest PyQt (4.7-1), then PyQwt 5.2.0, which was built with PyQt4.5.4. This line import PyQt4.Qwt5 as Qwt fails to load the DLL. Could this be the result of not using PyQt4 4.5.4? I guess I can answer my own question. As far as I can determine, PyQwt 5.2.0 needs PyQt 4.5.4 to work. -- http://mail.python.org/mailman/listinfo/python-list
PyQt4.7 and PyQwt5.2.0
I installed the latest PyQt (4.7-1), then PyQwt 5.2.0, which was built with PyQt4.5.4. This line import PyQt4.Qwt5 as Qwt fails to load the DLL. Could this be the result of not using PyQt4 4.5.4? -- http://mail.python.org/mailman/listinfo/python-list
Re: A more specific query ...
Dennis Lee Bieber wrote:
On Sat, 27 Feb 2010 13:00:32 +1300, Gib Bogle
declaimed the following in
gmane.comp.python.general:
The PyQt4 problem results from having copies of the Qt DLLs in directories that
are in the PATH, as Doug Bell discovered. In my case I have two programs that
use Qt, AMD CodeAnalyst and Matlab. If I rename BOTH these directories I can
import the PyQt4 modules.
And where are those PATH entries relative to the Python ones? You
may have to add the Python location to PATH /before/ the AMD and Matlab
entries. {I routinely -- once a year or so -- copy the PATH environment
variable to an editor, and reorder it so that the stuff I use most
occurs earlier in the list}
Well diagnosed! The others were all system environment variables, while the
PyQt4 PATH is mine, and therefore it was placed at the end. I've taken the AMD
and Matlab PATH entries out of the system list and put them after PyQt4 in my
PATH. Now peace and harmony are restored to my Python world.
Thanks
Gib
--
http://mail.python.org/mailman/listinfo/python-list
Re: A more specific query ...
The PyQt4 problem results from having copies of the Qt DLLs in directories that are in the PATH, as Doug Bell discovered. In my case I have two programs that use Qt, AMD CodeAnalyst and Matlab. If I rename BOTH these directories I can import the PyQt4 modules. Since this behaviour did not occur with Python 2.5 and the previous PyQt I was using (4.5, I think), it seems that something has changed either with Python 2.6 or with PyQt 4.7. It would be very nice to learn how to fix this without renaming directories, since I use Matlab frequently. Gib -- http://mail.python.org/mailman/listinfo/python-list
Re: A more specific query ...
The PyQt4 problem results from having copies of the Qt DLLs in directories that are in the PATH, as Doug Bell discovered. In my case I have two programs that use Qt, AMD CodeAnalyst and Matlab. If I rename BOTH these directories I can import the PyQt4 modules. Since this behaviour did not occur with Python 2.5 and the previous PyQt I was using (4.5, I think), it seems that something has changed either with Python 2.6 or with PyQt 4.7. It would be very nice to learn how to fix this without renaming directories, since I use Matlab frequently. Gib -- http://mail.python.org/mailman/listinfo/python-list
Re: A more specific query ...
The point of my question was that sys.path is clearly not being used in this case. When I start Python sys.path includes D:\python26\lib\site-packages which seems to be the Python default. Using sys.path.append I have tried adding both D:\python26\lib\site-packages\PyQt4 and D:\python26\lib\site-packages\PyQt4\bin to the path, but this has no effect. So far the only way I've found to make the PyQt4 DLLs visible to Python is by copying them from PyQt4\bin into PyQt4. I've tried adding stuff to the Windows PATH, but that has no effect. Gib Chris Rebert wrote: On Fri, Feb 26, 2010 at 12:45 PM, Gib Bogle wrote: How can I interrogate Python to find out where it is looking to find the PyQt4 DLLs in a Windows installation? import sys print(sys.path) Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: A more specific query ...
Chris Rebert wrote: On Fri, Feb 26, 2010 at 12:45 PM, Gib Bogle wrote: How can I interrogate Python to find out where it is looking to find the PyQt4 DLLs in a Windows installation? import sys print(sys.path) Note this thread: http://www.mail-archive.com/p...@riverbankcomputing.com/msg20121.html I'm starting to get the impression that Windows is the 'poor relation' in the Python family ... -- http://mail.python.org/mailman/listinfo/python-list
A more specific query ...
How can I interrogate Python to find out where it is looking to find the PyQt4 DLLs in a Windows installation? Secondarily, how is this search path set? -- http://mail.python.org/mailman/listinfo/python-list
PyQt 4.7 installation on Windows
I've just installed Python 2.6.4 and PyQt 4.7 on my Windows machine, on which I was using Python 2.5 and PyQt 4.5. Now 'from PyQt4 import QtGui' fails to find the DLL. Some googling shows that others have encountered the same problem, and a workaround is to copy QtGui4.dll (for example) from D:\Python26\Lib\site-packages\PyQt4\bin to D:\Python26\Lib\site-packages\PyQt4 This is obviously not a solution, just a clue. Another clue is that the Python 2.5 installation didn't have the \bin subdirectory, instead all the DLLs were in PyQt4. It looks as if for 2.6 the DLLs have been moved but the search path hasn't been changed. sys.path includes D:\python26\lib\site-packages, and the Windows PATH environment variable includes D:\Python26\Lib\site-packages\PyQt4\bin For some reason I have a sense of deja vu. Can anyone help? -- http://mail.python.org/mailman/listinfo/python-list
Re: Executable problem - socket?
MRAB wrote: You could try Dependency Walker: http://dependencywalker.com/ I have (belatedly) read the py2exe tutorial: http://www.py2exe.org/index.cgi/Tutorial#Step522 and learned about the msvcr90.dll issue. I haven't finished sorting this out yet, but I did find that running vcredist_x86.exe (the right version!) on box 1 fixed things there. I also tried (naively) manually adding dist\Microsoft.VC90.CRT with the manifest file and msvcr90.dll, but this doesn't seem to work - it seems that p2exe must do the file copying. -- http://mail.python.org/mailman/listinfo/python-list
Re: Executable problem - correction
Sean DiZazzo wrote: On Feb 24, 9:22 pm, Gib Bogle wrote: The program doesn't fail with the write error on the other XP machine, it actually fails to execute at all, complaining about the configuration information. Therefore I'm seeing different behaviour on three XP machines: Box 1 (SP2): runs OK Box 2 (SP3): fails to start Box 3 (SP3): starts up, all Qt stuff works, fails after invoking the Fortran DLL Just to add to the confusion, execution is successful on a Windows 7 box. I forgot to mention that the laptop on which the program was built (and where it runs OK) is using Vista. I now see that it will probably be necessary to build separate Vista and XP versions - I should have realized this earlier, but was misled by the fact that the Vista-built program runs OK on my XP SP2 box. Did you compile the program with python 2.6? Try compiling with 2.5. ~Sean I'll have to check with Helvin, but I believe 2.6 was needed for the version of PyQt that she has installed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Executable problem - correction
The program doesn't fail with the write error on the other XP machine, it actually fails to execute at all, complaining about the configuration information. Therefore I'm seeing different behaviour on three XP machines: Box 1 (SP2): runs OK Box 2 (SP3): fails to start Box 3 (SP3): starts up, all Qt stuff works, fails after invoking the Fortran DLL Just to add to the confusion, execution is successful on a Windows 7 box. I forgot to mention that the laptop on which the program was built (and where it runs OK) is using Vista. I now see that it will probably be necessary to build separate Vista and XP versions - I should have realized this earlier, but was misled by the fact that the Vista-built program runs OK on my XP SP2 box. -- http://mail.python.org/mailman/listinfo/python-list
Re: Executable problem - socket?
MRAB wrote: Gib Bogle wrote: Hi, My student has been developing a GUI (using PyQt and PyQwt) that runs a model written in Fortran and built as a DLL. She has to present on this work tomorrow. She makes an executable version of the Python code with py2exe, and the executable runs fine on her Vista laptop and my XP machine. It doesn't run on the PC that she must use for her talk tomorrow. The Fortran DLL code is started up, it writes some text output to a couple of log files, then it fails with a WindowsError (01d) which is a write error. I suspect that this is the first attempt to write to a socket (communication from the DLL to Python is via sockets). The only clue is that the machines that her program runs on have Python installed, while the one that fails doesn't. Therefore I suspect that py2exe has omitted a necessary Python DLL. How can I track down what might be missing? You could try Dependency Walker: http://dependencywalker.com/ Wow! I've heard of it, but never used it. The result is intriguing, but baffling. When I look at the executable ABM15.exe on my machine (where it runs OK), I see a couple of harmless messages, but interestingly the program shows up with a checksum inconsistency, between Link Checksum and Real Checksum. Apparently this causes no issues on my machine. On another XP machine, where the program fails with the write error, there is first a pop-up with this message: "Errors were detected when processing ABM15.exe. See the log for details." In the log there are two significant messages: "Error: The side-by-side configuration information for ABM15.exe contains errors. The application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001)." (the checksum discrepancy is there also) "MSJAVA.DLL Error opening file. The system cannot find the file specified (2)." (needless to say, I'm not using Java, and MSJAVA.dll is not on the other machine either) I find it very puzzling that the "configuration information" (whatever that is) is OK on one machine and erroneous on another. DependencyWalker is obviously onto something - but what? (At this stage snide comments about Windows will be received without comment.) -- http://mail.python.org/mailman/listinfo/python-list
Executable problem - socket?
Hi, My student has been developing a GUI (using PyQt and PyQwt) that runs a model written in Fortran and built as a DLL. She has to present on this work tomorrow. She makes an executable version of the Python code with py2exe, and the executable runs fine on her Vista laptop and my XP machine. It doesn't run on the PC that she must use for her talk tomorrow. The Fortran DLL code is started up, it writes some text output to a couple of log files, then it fails with a WindowsError (01d) which is a write error. I suspect that this is the first attempt to write to a socket (communication from the DLL to Python is via sockets). The only clue is that the machines that her program runs on have Python installed, while the one that fails doesn't. Therefore I suspect that py2exe has omitted a necessary Python DLL. How can I track down what might be missing? Thanks Gib -- http://mail.python.org/mailman/listinfo/python-list
Re: Files required for porting python
KIRAN wrote: "I see lot of code with several files." I had to laugh at this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem creating executable, with PyQwt
David Boddie wrote: On Tuesday 23 February 2010 05:32, Gib Bogle wrote: David Boddie wrote: I have previously referred people with py2exe/PyQt issues to this page on the PyQt Wiki: http://www.py2exe.org/index.cgi/Py2exeAndPyQt If you can somehow convince py2exe to include the QtSvg module (and presumably the libQtSvg library as well) then perhaps that will solve this problem. David Thanks David, that worked a treat. :-) If you could update the Wiki (or maybe the py2exe Wiki, if they have one) to say what you did, that would be useful for others in the future. Then they'll only be one search away from the answer. :-) David OK, I'll put it on the to-do list. Gib -- http://mail.python.org/mailman/listinfo/python-list
Re: Verifying My Troublesome Linkage Claim between Python and Win7
W. eWatson wrote: On 2/23/2010 11:14 AM, Gib Bogle wrote: W. eWatson wrote: On 2/23/2010 8:26 AM, Rick Dooling wrote: No telling what Windows will do. :) I am a mere hobbyist programmer, but I think real programmers will tell you that it is a bad habit to use relative paths. Use absolute paths instead and remove all doubt. http://docs.python.org/library/os.path.html RD You may be right. The actual 300 line program just reads the folder without specifying any path. I'm not that familiar with os path, but have seen it used. How do you invoke the program? Do you use a Command Prompt window? IDLE, but I'm prett sure I tried it (300 lines) with Cprompt. I don't know what you mean by "300 lines". Have you opened a Command Prompt window, changed to the directory where you copied the files, and executed: python your_prog.py ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Verifying My Troublesome Linkage Claim between Python and Win7
W. eWatson wrote: On 2/23/2010 8:26 AM, Rick Dooling wrote: No telling what Windows will do. :) I am a mere hobbyist programmer, but I think real programmers will tell you that it is a bad habit to use relative paths. Use absolute paths instead and remove all doubt. http://docs.python.org/library/os.path.html RD You may be right. The actual 300 line program just reads the folder without specifying any path. I'm not that familiar with os path, but have seen it used. How do you invoke the program? Do you use a Command Prompt window? -- http://mail.python.org/mailman/listinfo/python-list
Re: Verifying My Troublesome Linkage Claim between Python and Win7
Rick Dooling wrote: No telling what Windows will do. :) It isn't useful to respond to a serious question with OS bigotry. -- http://mail.python.org/mailman/listinfo/python-list
Re: What's Going on between Python and win7?
chris grebeldinger wrote: Have you tried opening file explorer in administrative mode before performing the copy? I think if there isn't sufficient permissions, it does something weird like that. No -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem creating executable, with PyQwt
David Boddie wrote: I have previously referred people with py2exe/PyQt issues to this page on the PyQt Wiki: http://www.py2exe.org/index.cgi/Py2exeAndPyQt If you can somehow convince py2exe to include the QtSvg module (and presumably the libQtSvg library as well) then perhaps that will solve this problem. David Thanks David, that worked a treat. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: What's Going on between Python and win7?
John Bokma wrote: Gib Bogle writes: MRAB wrote: W. eWatson wrote: Last night I copied a program from folder A to folder B. It inspects the contents of files in a folder. When I ran it in B, it gave the results for A! Out of frustration I changed the name in A, and fired up the program in B. Win7 went into search mode for the file. I looked at properties for the B program, and it was clearly pointing to folder A. Sounds like you didn't copy it but made a shortcut to it instead. Windows 7 has symbolic links? Symbolic links are designed to aid in migration and application compatibility with UNIX operating systems. Microsoft has implemented its symbolic links to function just like UNIX links. : Symbolic links are available in NTFS starting with Windows Vista. http://msdn.microsoft.com/en-us/library/aa365680(VS.85).aspx That explains my ignorance of this (excellent) development. I'm still using W2K and XP. -- http://mail.python.org/mailman/listinfo/python-list
Re: What's Going on between Python and win7?
MRAB wrote: W. eWatson wrote: Last night I copied a program from folder A to folder B. It inspects the contents of files in a folder. When I ran it in B, it gave the results for A! Out of frustration I changed the name in A, and fired up the program in B. Win7 went into search mode for the file. I looked at properties for the B program, and it was clearly pointing to folder A. Sounds like you didn't copy it but made a shortcut to it instead. Windows 7 has symbolic links? -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem creating executable, with PyQwt
Thanks David. Someone asked this question on the PyQt mailing list, too: http://www.riverbankcomputing.com/pipermail/pyqt/2010-February/025827.html That's my student, Helvin. I believe it was also asked on the #pyqt IRC channel on freenode. I think I have previously referred people with py2exe/PyQt issues to this page on the PyQt Wiki: http://www.py2exe.org/index.cgi/Py2exeAndPyQt If you can somehow convince py2exe to include the QtSvg module (and presumably the libQtSvg library as well) then perhaps that will solve this problem. I just did a quick test myself, and confirmed that this works for sip. I'm not at all clear what "--includes" arguments might be needed for QtSvg (and libQtSvg). I'll pass this info on to Helvin. Gib -- http://mail.python.org/mailman/listinfo/python-list
Problem creating executable, with PyQwt
My student is trying to build an executable version of a program that uses PyQt and PyQwt, on Windows XP. She has installed: Python 2.6.1, Qt 4.5.0, PyQt 4.5, and PyQwt 5.2.0. There is a module error on running the executable produced by py2exe. Here is the info I got from my student: Traceback (most recent call last): File "ABM15.pyw", line 15, in File "PyQt4\Qwt5\__init__.pyc", line 32, in File "PyQt4\Qwt5\Qwt.pyc", line 12, in File "PyQt4\Qwt5\Qwt.pyc", line 10, in __load ImportError: No module named QtSvg If you Google this last line, you'll find that I've posted this to a forum, but no one answered me. Someone has also had this problem before, although I think they were using PyInstaller and not py2exe. They say that its because Qwt has a hidden import for QtSvg. If I can turn this off, maybe it'll work, but I don't know how. I have downloaded py2exe and I run the attached setup.py file in my working directory. It creates two directories: 'dist' and 'build'. An executable is created in the 'dist' directory along with other things. When I tried running it, it produces a log file, in which I find the error messages. <\quote> Perhaps someone can recognize these symptoms. Thanks, Gib -- http://mail.python.org/mailman/listinfo/python-list
Re: Shipping Executables
Steven D'Aprano wrote: On Wed, 17 Feb 2010 02:00:59 -0500, geremy condra quoted Banibrata Dutta : BTW for people who are non-believers in something being worth stealing needing protection, need to read about the Skype client. Pardon me for breaking threading, but the original post has not come through to my provider, only the reply from Geremy. Many things are worth stealing and therefore need protection. In any case, reverse engineering software is not theft. And even if it were, keeping the source code secret is no barrier to a competent, determined attacker or investigator. Skype is a good example: despite the lack of source code and the secret protocol, analysts were able to discover that TOM-Skype sends personally identifiable information, encryption keys and private messages back to central servers. In my personal opinion, releasing closed source software is prima facie evidence that the software is or does something bad: leaking personal information, infringing somebody else's copyright or patent, or just being badly written. I'm not saying that every piece of closed source software is like that, but when you hide the source, the burden of proof is on you to prove that you're not hiding something unpleasant. You are assuming that everyone who might be interested in copying your code is able to reverse-engineer it. That might be true for software with a high commercial value, but it is by no means true for all software. And in saying "when you hide the source, the burden of proof is on you to prove that you're not hiding something unpleasant" you are tacitly assuming that the users of the software care about having such a thing proven. I submit that most users do not have this "guilty until proven innocent" attitude. To give a personal example: I plan soon to distribute (free) to anyone interested some scientific software. For various reasons I do not intend to distribute the source code at this stage. I'm quite confident that the users (biologists) will have neither the desire nor the ability to reverse-engineer it. Of course I'd be tremendously flattered if they did want to. I'm also confident that they will not suspect me of "hiding something unpleasant". In the worst case they might think the program is useless. -- http://mail.python.org/mailman/listinfo/python-list
Re: Please help with MemoryError
Steven D'Aprano wrote: def swap(a, b): a, b = b, a x = 1 y = 2 swap(x, y) assert (x == 2) and (y==1) Can't the same point be more simply made with this example: def setval(a): a = 12345 x = 1 setval(x) print x ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3 minor irritation
Gabriel Genellina wrote: Sorry, I should have removed that line. This is just my setup; a normal Python install doesn't create that registry entry. It allows Desktop Search (or Windows Search, or whatever it is called nowadays; the F3 key) to search inside .py files (default behavior is to just ignore their contents). See http://support.microsoft.com/kb/309173 Is this related to the fact that when I double-click on a .py file the command window disappears after the execution is completed? (I bet the "Persistent" word confused you.) No, as you can see, it's completely unrelated. AFAIK, there is no way (on XP and later at least) to keep a console window open after the program exited. Three choices: - Open a cmd window and execute the script there. You may drag&drop the file over the window to avoid typing the full path (I think this last part does not work on Vista nor Win7) - Add a raw_input() [2.x] or input() [3.x] line at the end of the script - Rename it with a '.cmd' extension and add this line at the very top: @(C:\Python26\Python -x %~f0 %* || pause) && goto:EOF (see this post by Duncan Booth last month: http://comments.gmane.org/gmane.comp.python.general/650913 ) Thanks Gabriel. I didn't know about the drag&drop capability (learn something every day, forget two things). BTW input() works for me in 2.5. Cheers Gib -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3 minor irritation
Gabriel Genellina wrote:
But the associated program might change the current directory - that's
not the case with the default associations created by the Python
installer, but one should verify this.
To the OP: please create this small test script
import os
print("curdir=", os.getcwd())
print("__file__=", __file__)
input()
and post what you get when you double-click on it.
Also, from the command line, execute:
D:\temp>reg query HKCR\.py
! REG.EXE VERSION 3.0
HKEY_CLASSES_ROOT\.py
REG_SZ Python.File
Content TypeREG_SZ text/plain
HKEY_CLASSES_ROOT\.py\PersistentHandler
I'm interested in this, because I'm using Windows XP, and when I execute this
command I see the first part but not the second (with PersistentHandler). Is
this related to the fact that when I double-click on a .py file the command
window disappears after the execution is completed?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python's Reference And Internal Model Of Computing Languages
Paul Rubin wrote: Ryan Kelly writes: I know, I know, do not feed the trolls. But this is just so *wrong* that I can't help myself. See: http://xkcd.com/386/ :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: myths about python 3
Ethan Furman wrote: Steven D'Aprano wrote: 4. Python 3 will make you irresistible to women. FALSE What?!? Drat!!! Guess I'll have to learn Lisp... ;) ~Ethan~ Learn to say this fast, you'll impress the hell out of them: Chaps with chapped lips lisp. -- http://mail.python.org/mailman/listinfo/python-list
Re: python 3's adoption
Luis M. González wrote: Please don't post more noise and ad hominem attacks to the group, Steve. "Ad hominem"? Please, operor non utor lingua non notus per vulgaris populus. Gratias ago vos... "ad hominem" is "lingua notus per vulgaris populus", the vulgar pop of these parts, anyway. -- http://mail.python.org/mailman/listinfo/python-list
Re: python 3's adoption
Steven D'Aprano wrote: On Wed, 27 Jan 2010 02:28:00 +0100, Alf P. Steinbach wrote: * Print is now a function. Great, much improvement. Actually not, IMHO. All it does is is to provide incompatibility. They forgot Ronald Reagan's old maxim: if it don't need fixin', don't fix it. The aphorism needs fixing: If it ain't broke, don't fix it. -- http://mail.python.org/mailman/listinfo/python-list
Re: py2exe and pydocs. Downloads?
Gabriel Genellina wrote: En Wed, 20 Jan 2010 21:22:19 -0300, Gib Bogle escribió: Gabriel Genellina wrote: c:\temp>python -m pydoc sys Help on built-in module sys: [...same info...] When I do this I get: No module named tempfile You found a bug. Looks like it depends on the environment, or what packages are installed, or something like that, because it worked on my other PC but not here. Please report it at http://bugs.python.org so it doesn't get forgotten. The bug checkers are not able to reproduce the error. What is your other PC running? -- http://mail.python.org/mailman/listinfo/python-list
Re: py2exe and pydocs. Downloads?
Gabriel Genellina wrote: You found a bug. Looks like it depends on the environment, or what packages are installed, or something like that, because it worked on my other PC but not here. Please report it at http://bugs.python.org so it doesn't get forgotten. Done -- http://mail.python.org/mailman/listinfo/python-list
Re: py2exe and pydocs. Downloads?
Gabriel Genellina wrote: c:\temp>python -m pydoc sys Help on built-in module sys: [...same info...] When I do this I get: No module named tempfile -- http://mail.python.org/mailman/listinfo/python-list
Re: syntax
Looks like homework. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a list compression in Python?
Kit wrote: Thank you so much guys. Just out of curiosity: can I do something like this to "square all even numbers in the range 1-10"? print [x^2 for x in range (1,11) if x % 2 == 0] Why not try it? -- http://mail.python.org/mailman/listinfo/python-list
PyQwt installation
Should there be a problem installing PyQwt5.2.0 with PyQt4.4.4 and Python2.6 on Windows? My student is saying she can't get the Windows installer to work, and she points out that the download site says "Binary installation of PyQwt-5.2.0 on Windows for Python-2.6.x, PyQt-4.5.4" -- http://mail.python.org/mailman/listinfo/python-list
Re: ctypes error
Gib Bogle wrote: It has occurred to me that the error may have nothing to do with ctypes. The DLL was built on one machine and copied to the other (which doesn't have the compiler installed). Although both machines are running Windows XP, there might be some subtle differences. I see that the build machine has XP Professional, Version 2002, Service Pack 2, while the machine that fails to load the DLL has XP Home Edition, Version 2002, Service Pack 3. Who knows. I'm a bit embarrassed to report that the problem has nothing to do with Python. My DLL was built with dynamic library linking, and apparently there are some differences between the various Intel DLLs used on the two machines. Following advice from the Intel Fortran forum, I created the DLL with static library linking, and now all works as expected. Sorry to waste your time. -- http://mail.python.org/mailman/listinfo/python-list
Re: ctypes error
It has occurred to me that the error may have nothing to do with ctypes. The DLL was built on one machine and copied to the other (which doesn't have the compiler installed). Although both machines are running Windows XP, there might be some subtle differences. I see that the build machine has XP Professional, Version 2002, Service Pack 2, while the machine that fails to load the DLL has XP Home Edition, Version 2002, Service Pack 3. Who knows. -- http://mail.python.org/mailman/listinfo/python-list
ctypes error
I have a simple demo program (on Windows XP) that uses the ctypes module to load
a DLL. This program works as expected with Python 2.5.4, but fails with Python
2.6.4 (on a different machine, each machine has only one Python version
installed), with these messages:
File "demo.py", line 37, in
mydll = windll.LoadLibrary("DEMO.DLL")
File "c:\python26\lib\ctypes\__init__.py, line 431, in LoadLibrary
return self._dlltype(name)
File "c:\python26\lib\ctypes\__init__.py, line 353, in __init__
self._handle = _dlopen(self._name, mode)
WindowsError: [Error 14001] This application has failed to start because the
application configuration is incorrect. Reinstalling the application may fix
this problem
It isn't clear to me what the "application" is. As far as I know I didn't
install anything except Python 2.6.4. Is it possible that ctypes doesn't work
with 2.6.4?
--
http://mail.python.org/mailman/listinfo/python-list
Re: A question about Python versions
Terry Reedy wrote: On 1/13/2010 1:09 AM, Gib Bogle wrote: I am learning Python, and using PyQt to develop a GUI that will be used to run a Fortran program on Windows, Linux and Mac OS X (I think Python is great, btw). Without thinking about it I downloaded and started working with a fairly recent Python version, 2.5.4. I've now become aware of the existence of Python 3.1, which apparently is a major revision of the language. Does it make sense to stick with Python 2.x at this point, or should I be starting off with 3.1? If it is recommended to stick with version 2, should I use the latest (2.6.4 or 2.7), and if so why? Thanks. My view is that if PyQt works with 3.1 (I have the impression it does but may be wrong) and that is the only 3rd parth library you need, or anything else you need works with 3.1, then strongly consider 3.1 for new code. The main difference between 2.6 and 3.1 is the number of old, obsolete things removed that you will not even be tempted to learn about. Terry Jan Reedy On balance I think I'll stick with 2.x - another factor I didn't mention is that most end-users will probably not have 3.x installed on their machines. -- http://mail.python.org/mailman/listinfo/python-list
Re: A question about Python versions
Sridhar Ratnakumar wrote: On 1/12/2010 10:09 PM, Gib Bogle wrote: I am learning Python, and using PyQt to develop a GUI that will be used to run a Fortran program on Windows, Linux and Mac OS X (I think Python is great, btw). Without thinking about it I downloaded and started working with a fairly recent Python version, 2.5.4. I've now become aware of the existence of Python 3.1, which apparently is a major revision of the language. Does it make sense to stick with Python 2.x at this point, or should I be starting off with 3.1? Stick with 2.x. If it is recommended to stick with version 2, should I use the latest (2.6.4 or 2.7), and if so why? Thanks. 2.6.4 definitely (as 2.7 final is not released yet). Also see: http://stackoverflow.com/questions/170921 -srid Thanks, very useful. -- http://mail.python.org/mailman/listinfo/python-list
A question about Python versions
I am learning Python, and using PyQt to develop a GUI that will be used to run a Fortran program on Windows, Linux and Mac OS X (I think Python is great, btw). Without thinking about it I downloaded and started working with a fairly recent Python version, 2.5.4. I've now become aware of the existence of Python 3.1, which apparently is a major revision of the language. Does it make sense to stick with Python 2.x at this point, or should I be starting off with 3.1? If it is recommended to stick with version 2, should I use the latest (2.6.4 or 2.7), and if so why? Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Threading change, 2.5.4 -> 2.6.1
MRAB wrote: Gib Bogle wrote: The code below runs with Python 2.5.4, but gives the following error messages with Python 2.6.1. What needs to be done to make it work? Thanks. C:\Summer09\Tutorials>python url_queue.pyw Traceback (most recent call last): File "url_queue.pyw", line 3, in import threading File "C:\Summer09\Tutorials\threading.py", line 9, in class ProcessingThread(threading.Thread, QtCore.QObject): AttributeError: 'module' object has no attribute 'Thread' [snip] url_queue.pyw is trying to import Python's "threading" module, but it's finding the threading.py script in your "Tutorials" folder first. Renaming your tutorial script to something other than "threading.py". Thanks very much to you both. It's actually not in my folder, it is (presumably) in my student's folder (I'm the one using 2.5.4, she has 2.6.1 and thought this could be the problem.) -- http://mail.python.org/mailman/listinfo/python-list
Threading change, 2.5.4 -> 2.6.1
The code below runs with Python 2.5.4, but gives the following error messages with Python 2.6.1. What needs to be done to make it work? Thanks. C:\Summer09\Tutorials>python url_queue.pyw Traceback (most recent call last): File "url_queue.pyw", line 3, in import threading File "C:\Summer09\Tutorials\threading.py", line 9, in class ProcessingThread(threading.Thread, QtCore.QObject): AttributeError: 'module' object has no attribute 'Thread' url_queue.py #!/usr/bin/env python import Queue import threading import urllib2 import time hosts = ["http://yahoo.com";, "http://google.com";, "http://amazon.com";, "http://ibm.com";, "http://apple.com";] queue = Queue.Queue() class ThreadUrl(threading.Thread): #"""Threaded Url Grab""" def __init__(self, queue,i): threading.Thread.__init__(self) self.queue = queue self.num = i print "Thread: ",self.num def run(self): while True: #grabs host from queue host = self.queue.get() print "num, host: ",self.num,host #grabs urls of hosts and prints first 1024 bytes of page url = urllib2.urlopen(host) print url.read(1024) #signals to queue job is done self.queue.task_done() start = time.time() def main(): #spawn a pool of threads, and pass them queue instance for i in range(5): t = ThreadUrl(queue,i) t.setDaemon(True) t.start() #populate queue with data for host in hosts: queue.put(host) #wait on the queue until everything has been processed queue.join() main() print "Elapsed Time: %s" % (time.time() - start) -- http://mail.python.org/mailman/listinfo/python-list
Re: A null program - what is it doing?
r0g wrote: Gib Bogle wrote: No doubt a dumb question from a noob: The following program (a cut down version of some test code) uses no CPU, and does not terminate: import sys from PyQt4.QtCore import * if __name__=="__main__": app = QCoreApplication(sys.argv) sys.exit(app.exec_()) What is the program doing? What is the correct way to terminate the execution? Thanks in advance for educating me. I've never used QT but other graphical toolkits I have used all start their own "main loop" which is a loop that cycles round receiving, queuing and dispatching "events". You probably need to call the QCoreApplication's quit method to break out of this e.g. app.exit() or something similar, have a look at some complete PyQt4 examples or google for PyQt4 mainloop. Roger. Thanks. I've realized that QCoreApplication (or QApplication) manages the event loop, and normally when it is executed you are showing a widget of some kind, closing which ends the application. Alt-F4 acts like Ctrl-C to terminate from the keyboard. -- http://mail.python.org/mailman/listinfo/python-list
A null program - what is it doing?
No doubt a dumb question from a noob: The following program (a cut down version of some test code) uses no CPU, and does not terminate: import sys from PyQt4.QtCore import * if __name__=="__main__": app = QCoreApplication(sys.argv) sys.exit(app.exec_()) What is the program doing? What is the correct way to terminate the execution? Thanks in advance for educating me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Threading with queues
Lie Ryan wrote: On 12/22/2009 10:47 AM, Gib Bogle wrote: This is indented over one indentation level too much. You want it to be at the same level as the for above. Here, its at the same level with "t" -- meaning this entire loop gets repeated five times. I sorta really recommend a tab width of 4 spaces, not 2 :) At 2, its _really_ hard (especially if you're newer to Python) to see these kinds of issues and since indentation is program logic and structure in Python, that's bad... especially since your comment is indented to the right level, but the code isn't :) --S It turns out that this code isn't a great demo of the advantages of threading, on my system anyway. The time taken to execute doesn't vary much when the number of threads is set anywhere from 1 to 6. it does in mine: Elapsed Time: 7.4737711 (with one thread) Elapsed Time: 1.9015041 (with five threads) what sort of weird machine are you in? Hmmm, interesting. I am running Windows XP on Intel quad core hardware, Q6600. And you? -- http://mail.python.org/mailman/listinfo/python-list
Re: numpy performance and random numbers
David Cournapeau wrote: On Sun, Dec 20, 2009 at 6:47 PM, Lie Ryan wrote: On 12/20/2009 2:53 PM, sturlamolden wrote: On 20 Des, 01:46, Lie Ryan wrote: Not necessarily, you only need to be certain that the two streams don't overlap in any reasonable amount of time. For that purpose, you can use a PRNG that have extremely high period like Mersenne Twister and puts the generators to very distant states. Except there is no way to find two very distant states and prove they are distant enough. Except only theoretical scientist feel the need to prove it and perhaps perhaps for cryptographic-level security. Random number for games, random number for tmp files, and 99.99% random number users doesn't really need such proves. But the OP case mostly like falls in your estimated 0.01% case. PRNG quality is essential for reliable Monte Carlo procedures. I don't think long period is enough to guarantee those good properties for // random generators - at least it is not obvious to me. David My simulation program is Monte Carlo, but the complexity and variety of all the interactions ensure that PRNG sequence overlap will have no discernible effect. -- http://mail.python.org/mailman/listinfo/python-list
Re: Threading with queues
Stephen Hansen wrote: On Mon, Dec 21, 2009 at 3:12 PM, Gib Bogle wrote: #spawn a pool of threads, and pass them queue instance for i in range(5): t = ThreadUrl(queue,i) t.setDaemon(True) t.start() #populate queue with data for host in hosts: queue.put(host) This is indented over one indentation level too much. You want it to be at the same level as the for above. Here, its at the same level with "t" -- meaning this entire loop gets repeated five times. I sorta really recommend a tab width of 4 spaces, not 2 :) At 2, its _really_ hard (especially if you're newer to Python) to see these kinds of issues and since indentation is program logic and structure in Python, that's bad... especially since your comment is indented to the right level, but the code isn't :) --S It turns out that this code isn't a great demo of the advantages of threading, on my system anyway. The time taken to execute doesn't vary much when the number of threads is set anywhere from 1 to 6. -- http://mail.python.org/mailman/listinfo/python-list
Re: Threading with queues
Stephen Hansen wrote: On Mon, Dec 21, 2009 at 3:12 PM, Gib Bogle wrote: #spawn a pool of threads, and pass them queue instance for i in range(5): t = ThreadUrl(queue,i) t.setDaemon(True) t.start() #populate queue with data for host in hosts: queue.put(host) This is indented over one indentation level too much. You want it to be at the same level as the for above. Here, its at the same level with "t" -- meaning this entire loop gets repeated five times. I sorta really recommend a tab width of 4 spaces, not 2 :) At 2, its _really_ hard (especially if you're newer to Python) to see these kinds of issues and since indentation is program logic and structure in Python, that's bad... especially since your comment is indented to the right level, but the code isn't :) --S Aarrh! Caught by the obvious Python trap that everyone knows about! In my defense, it's wrong on the web site. I agree, 4 spaces is the best plan. Thanks very much! -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python to Execute a C or FORTRAN Program (Windows)
W. eWatson wrote: Mensanator wrote: On Dec 14, 8:14�pm, "W. eWatson" wrote: I think Python is capable of executing a compiled C or FORTRAN program, Sure, if it was compiled to an .exe file. and maybe even getting some parameters passed back. Sure, if the program prints to stdout. Does anyone have a example of how this might be done? I'm running under Win XP Pro. Here's one. The test program is factor.exe (included in the MIRACL library). I recompiled it (factor!.exe) to produce consitent output. ... Thanks. OK, I think I can follow that. I want to pass it along to someone who either missed this possibility in some coding, ignored it, or felt more comfortable about just writing the whole program from scratch in c++. His program was originally written in Python, but a new hardware device (capture card) had no good interface with Python, so he wrote it in C++, which does. From my knowledge of the Python program before the entry of c++, it seems he could have farmed out the hardware interface in much the same way he had done it before with a capture card well know to him. Would the same Python interface work for a compiled C++ program? I am working on a Python UI (PyQt4) to a Fortran program. The approach I've taken is to build the Fortran code as a DLL (or .so). Python can load the library and call a procedure that initiates execution. I'm using sockets to pass data of different types back to the Python program. This is a work in progress, and I'm learning Python as we go. -- http://mail.python.org/mailman/listinfo/python-list
Re: numpy performance and random numbers
sturlamolden wrote: On 19 Des, 22:58, sturlamolden wrote: If you pick two random states (using any PRNG), you need error- checking that states are always unique, i.e. that each PRNG never reaches the starting state of the other(s). Another note on this: Ideally, we would e.g. know how to find (analytically) MT states that are very far apart. But to my knowledge no such equation has been derived. But often in Monte Carlo simulations, the PRNG is not the dominant computational bottleneck. So we can simply start N PRNGs from N consequtive states, and for each PRNG only use every N-th pseudorandom deviate. OK, now I understand. In my application I don't care about a thread's PRNG reaching the start of another threads. I do understand that this is not the case in all applications. -- http://mail.python.org/mailman/listinfo/python-list
Re: numpy performance and random numbers
sturlamolden wrote: On 19 Des, 16:20, Carl Johan Rehn wrote: How about mulit-core or (perhaps more exciting) GPU and CUDA? I must admit that I am extremely interested in trying the CUDA-alternative. Obviously, cuBLAS is not an option here, so what is the safest route for a novice parallel-programmer? The problem with PRNG is that they are iterative in nature, and maintain global states. They are therefore very hard to vectorize. A GPU will not help. The GPU has hundreds of computational cores that can run kernels, but you only get to utilize one. Parallel PRNGs are an unsolved problem in computer science. My parallel version of ziggurat works fine, with Fortran/OpenMP. -- http://mail.python.org/mailman/listinfo/python-list
Re: numpy performance and random numbers
sturlamolden wrote: On 19 Des, 14:06, Carl Johan Rehn wrote: Matlab and numpy have (by chance?) the exact names for the same functionality, Common ancenstry, NumPy and Matlab borrowed the name from IDL. LabView, Octave and SciLab uses the name randn as well. So the basioc question is, how can I speed up random number generation? The obvious thing would be to compile ziggurat yourself, and turn on optimization flags for your hardware. http://www.jstatsoft.org/v05/i08/ P.S. Be careful if you consider using more than one processor. Multithreading is a very difficult issue with PRNGs, becuase it is difficult to guarrantee they are truely independent. But you can use a producer-consumer pattern, though: one thread constantly producing random numbers (writing into a buffer or pipe) and another thread(s) consuming them. In case you're interested, I've made a multi-thread version of ziggurat (actually in Fortran for use with OpenMP). It is a simple enough mod, there is an additional argument (thread number) in each call to the ziggurat functions, and ziggurat maintains separate variables for each thread (not just the seed). There was one non-trivial issue. To avoid cache collisions, the seed values (an array corresponding to jsr in the original code) need to be spaced sufficiently far apart. Without this measure the performance was disappointingly slow. I agree with your recommendation - ziggurat is really fast. -- http://mail.python.org/mailman/listinfo/python-list
Threading with queues
Hi, I'm learning Python, jumping in the deep end with a threading application. I came across an authoritative-looking site that recommends using queues for threading in Python. http://www.ibm.com/developerworks/aix/library/au-threadingpython/index.html The author provides example code that fetches data from several web sites, using threads. I have modified his code slightly, just adding a couple of print statements and passing an ID number to the thread. #!/usr/bin/env python import Queue import threading import urllib2 import time hosts = ["http://yahoo.com";, "http://google.com";, "http://amazon.com";, "http://ibm.com";, "http://apple.com";] queue = Queue.Queue() class ThreadUrl(threading.Thread): #"""Threaded Url Grab""" def __init__(self, queue,i): threading.Thread.__init__(self) self.queue = queue self.num = i print "Thread: ",self.num def run(self): while True: #grabs host from queue host = self.queue.get() print "num, host: ",self.num,host #grabs urls of hosts and prints first 1024 bytes of page url = urllib2.urlopen(host) print url.read(1024) #signals to queue job is done self.queue.task_done() start = time.time() def main(): #spawn a pool of threads, and pass them queue instance for i in range(5): t = ThreadUrl(queue,i) t.setDaemon(True) t.start() #populate queue with data for host in hosts: queue.put(host) #wait on the queue until everything has been processed queue.join() main() print "Elapsed Time: %s" % (time.time() - start) Executed on Windows with Python 2.5 this program doesn't do what you want, which is to fetch data from each site once. Instead, it processes the first host in the list 5 times, the next 4 times, etc, and the last just once. I don't know whether it is a case of the code simply being wrong (which seems unlikely), or the behaviour on my system being different from AIX (also seems unlikely). Naively, I would have expected the queue to enforce processing of its members once only. Is there a simple change that will make this code execute as required? Or is this author out to lunch? Cheers Gib -- http://mail.python.org/mailman/listinfo/python-list
Re: BUSTED!!! 100% VIDEO EVIDENCE that WTC7 was controlled demolition!! NEW FOOTAGE!!! Ask yourself WHY havn't I seen this footage before?
Ah, so the firefighters were in on the conspiracy! -- http://mail.python.org/mailman/listinfo/python-list
Re: Video: Professor of Physics Phd at Cal Tech says: 911 Inside Job
[EMAIL PROTECTED] wrote: > Cal Tech is the ELITE of ELITE in physics. > > If Feynman were alive, he would point his finger straight at the 911 > criminal operators, the yank bastards themselves ... > > http://www.911blogger.com/node/8101 > > No self-respecting scientist should keep his mouth shut. Its a > fundamental challenge to the method of science, a detective work most > demanding of INTELLECTUAL HONESTY. > When did the University of Iowa (Iowhere?) become CalTech. -- http://mail.python.org/mailman/listinfo/python-list
