Thanks for your reply. I am most appreciative of your detailed response.

Please see below for my comments.

On 05/15/2019 08:12 PM, Steven D'Aprano wrote:
Hi Stephen,

My responses are interleaved with your comments below. Please excuse the
length of my post, but your problem is a complicated one.


On Wed, May 15, 2019 at 08:16:02AM -0400, Stephen P. Molnar wrote:
I am writing scripts to semi-automate some of my Quantum Chemistry
software and have encountered a problem that has me baffled. The two
scripts have the same form, the only difference being the commands. One
script works, the other bombs.
A note on terminology: to programmers, the terminology "bombs" usually
refers to a fatal application crash detected by the operating system:

https://en.wikipedia.org/wiki/Bomb_%28icon%29

whereas what you are experiencing is merely an exception with a
traceback displayed. The difference is that a "bomb" (or a "crash") is a
serious bug in the application (Python), while an exception is actually
a sign that Python is working correctly.

The bottom line is that there's not much you can do about a bomb except
stop running the script, whereas an exception means there's a bug in
your code you can fix.


My use of computers in my scientific work goes back to the early 1960's as a graduate student when I took an introductory course in FORTRAN II. I am a Chemist and not a professional programmer, although I occasionally write a FORTRAN program, thanks to Linux and gfortran. Although retired, I am still maintaining a computational chemistry research program.

So, substitute 'bug' for 'bomb' in this thread.
The script that works is:
[...]

Thanks for the careful and detailed samples of your code, but in general
unless you are paying a consultant to to the work for you, it is best to
try to narrow down the samples to the smallest amount that demonstrates
the problem. We're volunteers, donating our time for free, and often
with very limited time to offer. Every extra line of code you present us
with discourages us a little more from tackling your problem, so the
smaller the amount of code, the more likely we are to help.

For a better explanation, you might like to read this:

http://www.sscce.org/

It is written for Java programmers but applies to any language.



#!/usr/bin/env python
This line tells a Unix system to run the script using "python", which is
probably going to be Python 2. But I see from your code below that you
are actually running Python 3 code. So this is a potential problem. I
cannot tell if it is *actually* a problem right now, or will only become
one in the future.

You could try replacing the word "python" with "python3", but you should
run these commands at the Unix shell first:

     env python
     env python3

and see what they say.

Another problem is that both of your scripts call out to an external
script `pythonsh` which we cannot see, so there's no way of knowing what
that is doing.

Pythonsh is a bash script, a part of MGL_Tools (http://mgltools.scripps.edu/) which is the source of prepare_ligand4.py and prepare_dpf4.py which I am attempting to implement in my two scripts. MGL_Tools is a gui for AutoDock which, in turn I have been using for at least 25 years now. (Both MGL_Tools and AutoDock are open source and have been widely used.)

The function of pythonsh is to establish an environment for the use of python2 and to set a number of paths.. If I invoke pythonsh in a bash shell I get:

comp@AbNormal:/sdc1/Apps/Models/1-NerveAgents/Scripts$ ./pythonsh
setting PYTHONHOME environment
Python 2.5.6 (r256:88840, Nov  6 2012, 15:29:26)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

The second script refers to yet another Python script
`prepare_pdf4.py` but the output says this file doesn't exist:

can't open file
'./prepare_pdf4.py': [Errno 2] No such file or directory


So that's a problem you need to fix. I have no idea if that will fix
everything, or just part of the issue.



The problem may not be the invocation of prepare_dpf4.py, because:

comp@AbNormal:/sdc1/Apps/Models/1-NerveAgents/Ligands$ ./pythonsh ./prepare_dpf4.py
prepare_dpf4.py: ligand and receptor filenames
                    must be specified.
Usage: prepare_dpf4.py -l pdbqt_file -r pdbqt_file
    -l ligand_filename
    -r receptor_filename

Optional parameters:
    [-o output dpf_filename]
    [-i template dpf_filename]
    [-x flexres_filename]
    [-p parameter_name=new_value]
    [-k list of parameters to write]
    [-e write epdb dpf ]
    [-v] verbose output
    [-L] use local search parameters
    [-S] use simulated annealing search parameters
    [-s] seed population using ligand's present conformation

Prepare a docking parameter file (DPF) for AutoDock4.

   The DPF will by default be <ligand>_<receptor>.dpf. This
may be overridden using the -o flag.

Then:

/sdc1/Apps/Models/1-NerveAgents/Ligands$ ./pythonsh ./prepare_dpf4.py -l VM.pdbqt -ro apo-1acl.pdbqt

which results in:

/sdc1/Apps/Models/1-NerveAgents/Ligands$ l *.dpf
-rw-r--r-- 1 comp comp 2892 May 16 08:20 VM_o.dpf

Now, the only problem here is that the file name should be 'VM.dpf' not 'VM_o.dpf'. However, I'll worry about that later. incidentally, the contents of the file are correct.

while the script that bombs is:

[...]
Traceback (most recent call last):

   File "<ipython-input-1-078e132fa938>", line 1, in <module>
runfile('/home/comp/Apps/Models/1-NerveAgents/Ligands/calc_pdf.py',
wdir='/home/comp/Apps/Models/1-NerveAgents/Ligands')

   File
"/home/comp/Apps/miniconda3/lib/python3.7/site-packages/spyder_kernels/customize/spydercustomize.py",
line 824, in runfile
     execfile(filename, namespace)
This tells me that you are running your code via the Spyder IDE. That
means you have *at least* five and maybe six components involved:


- the Python interpreter
- which runs the Spyder IDE
- which runs your script
- which runs the mystery file pythonsh;
- which does something (runs it?) with the prepare_ligands4.py
   file or the (missing) prepare_pdf4.py file;
- which does who knows what.

Yes, I do use Spyder. I like the Variable Explorer feature. However, I get the same results when using Geany or the command line.
When having problems debugging this code, it helps to simplify the
problem by cutting Spyder out of the chain. If you run your script
directly, using a command like

     python3 path/to/the/script.py

does the error go away? I suspect not, but you can keep that in mind for
future debugging.



   File
"/home/comp/Apps/miniconda3/lib/python3.7/site-packages/spyder_kernels/customize/spydercustomize.py",
line 110, in execfile
     exec(compile(f.read(), filename, 'exec'), namespace)

   File "/home/comp/Apps/Models/1-NerveAgents/Ligands/calc_pdf.py", line
23, in <module>
     print ('Subprocess FAILED:', proc.command)

AttributeError: 'Popen' object has no attribute 'command'

Yes, I will grant the error 'AttributeError: 'Popen' object has no attribute 'command' ' i s there, but, if I run the other script with the same commands, I get:

.
.
.


None

None

None

None


------------------
(program exited with code: 0)
Press return to continue

with the Geany IDE, and the corresponding <ligand>.pdbqt from <ligand>.mol2 files are generated.

This is the mayor reason for my confusion and frustration!
That error message is completely correct: Popen objects don't have an
attribute called "command".

You are tring to print your own error message, referring to
"proc.command" but there is no such thing. What are you trying to do?
You need to find another way to do it.



If this is the case, why:


     17.1.4.5. Replacing |os.popen()|
     <https://docs.python.org/2/library/os.html#os.popen>,
     |os.popen2()|
     <https://docs.python.org/2/library/os.html#os.popen2>,
     |os.popen3()| <https://docs.python.org/2/library/os.html#os.popen3>

pipe  =  os.popen("cmd",  'r',  bufsize)
==>
pipe  =  Popen("cmd",  shell=True,  bufsize=bufsize,  stdout=PIPE).stdout

as a result of a web search? Just what is "cmd"?

Finally, my apologies for not hewing to the tenants of: http://www.sscce.org, and being rather verbose..

--
Stephen P. Molnar, Ph.D.          Life is a fuzzy set
www.molecular-modeling.net         Stochastic and multivariate
(614)312-7528(c)
Skype:  smolnar1

_______________________________________________
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Reply via email to