[Tutor] Pass arguments from bash script to embedded python script

[Stephen P. Molnar]

On 10/25/2019 04:38 AM, David L Neil via Tutor wrote:
> On 25/10/19 2:23 AM, Stephen P. Molnar wrote:
>> Thank you for your reply.
>>
>> Here is my code as formatted, with extraneous print statements removed:
>
> Thanks - much easier to read.
>
> Don't forget to review solid advice given in several earlier responses!
>
>
>> Please see my additional comments interspaced below:
>> On 10/23/2019 05:52 PM, David L Neil via Tutor wrote:
>>> On 24/10/19 8:08 AM, Stephen P. Molnar wrote:
>>> Back in FORTRAN we used to write:
> ...
>
>> Lost in the mist of time (the early 1960's) I was barely proficient 
>> in FORTRAN II.
>
> Evidently thought you were someone else, with a FORTRAN history.
>
> Back then I had hundreds of 101-students who became "barely 
> proficient" in F-II, but went-on to do great things!
>
>>> Apparently the same varNM is being used and re-used, for quite 
>>> different purposes!
>
> This (and other earlier critique) still evident (but am assuming 
> you've been addressing, pending this/further replies)
>
>
> ...
>
>>> 1 scan the currentDIR for .log files (existing)
>>> 2 manipulate the fileNM (existing)
>>> 3 dG() it (existing)
>
> (above retained because is expanded, below)
>
>
>>> Apologies, if seeming pedantic, but an incorrect choice of varNM may 
>>> introduce a confusion which prevents comprehension/debugging.
>>>
>> Well, I'm certainly  confused!! (I can be pedantic along with the best.)
>
> We can see that, but are confident that as the 'rules' coalesce in 
> your mind, what we are saying will become clear...
>
>
> The solution is like any other problem in ComSc: break the larger 
> problem down into smaller units, 'rinse and repeat', until the next 
> unit before you is solvable...
>
> Hence the idea that Python's REPR allows one to enter code 
> line-by-line and observe immediate results - quickly proving or 
> disproving a solution-attempt. However, please read on, gentle reader, 
> read on...
>
>
>>> Good idea to use some 'debug prints'! Even better, that if you are 
>>> using r3.8 you can take advantage of a brand-new feature:
> ...
>
>> I have enough problems iwth 3.7.
>
> Few/no other 'upgrades' (such as I have found, to-date) are likely to 
> bother you/us - but that one advantage is quite compelling. (IMHO)
>
> That said, if you are using Anaconda or some similar tool-set, you 
> will need to wait until they offer an r38 update (I don't know if/when).
>
>
>>> To help with learning Python, are you aware that Python allows, even 
>>> enables, you to experiment and thus develop a program, line-by-line?
>>>
>>> - open a terminal window and start python3
>>> - try these two lines (abstracted from the code):
>>>
>>> import glob
>>> glob.glob("*.log")
>>>
>> So far, so good:
>>
>>> #!/usr/bin/env python3
>>> # -*- coding: utf-8 -*-
>>> """
>>> Created on Thu Oct 24 08:48:59 2019
>>>
>>> """
>>>
>>> import glob
>>>
>>> ligands =[]
>>> ligands = glob.glob("*.log")
>
> Good work.
>
> Referring back to the docs-snippet on glob (quoted previously), glob 
> returns a *list*. Python does not require one to declare a variable as 
> having a data-type and/or an initial value - known as "duck typing". 
> In this case, the assignment takes the glob result/list and thus 
> 'says' ligands is (now) a list.
>
> This idea is both a massive advantage and time-save, but as you have 
> read in many of the replies to this thread, also one which can trip-up 
> the unwary and the learner - because one can say, and Python will 
> cheerfully oblige:
>
>     ligands = []    # making ligands a list
>     ligands = "abc"    # making ligands (now) a string, and
>     ligands = 3.14    # making ligands (now) numeric.
>
> NB this would be illegal/rejected by many other languages.
>
> Hence the advice about being careful in one's choice of 
> variable-names, and suggesting that the chosen-name indicate both form 
> and function. Thus (perhaps):
>
>     files_list = glob...
>
> However, most?many style conventions dislike explicit use of 
> type-words, eg list, dict, int; despite it being common in other 
> languages, eg MSFT 'standards' - and the Zen of Python recommending 
> "explicit over implicit". If it helps comprehension, I certainly won't 
> call the 'style police' on you, and particularly not whilst learning!
>
>
>>> - you should see something like (your):
>>>
>>>     ['C-VX3', '15-7', '14-7'] 
>>
>> That's what was returned.
>
> Proof!
>
>
> >> You can continue adding (your) lines of code, one-at-a-time. (in which
> >> case, at least initially, avoid loops and aim to get (only) 'the first
> >> one' to work). Once you have learned the necessary Python syntax and
> >> bent the code to your will, the pertinent/working parts can be copied
> >> into a editor and saved as a file. Then you can install loops (and
> >> indents!) and all the bells-and-whistles your little heart desires...
> >>
> >> Sage advice passed to a (much) younger me: "Make it work, before you
> >> make it better". Python's "REPR" makes enacting such advice SO much
> >> easier!
>
> So, now you can move on to the next sub-problem:
> - you have the (three) file names
> - don't bother with a loop, try to solve the single problem first
> - take the first fileNM
>
>     ligands[ 0 ]
> or
>     glob.glob( "*.log" )[ 0 ]
>
> - split the fileNM
> (and prove (to yourself) that you have the base fileNM and the 
> extension/suffix - see also PSL's os.path.split().)
> - assemble the output fileNM
> (per the idea of ignoring the loop, above, ignore the function and 
> test/prove the code using the first fileNM, without thought of 
> repetition)
> - check the np.get
> - attempt the output file-save
> - inspect the results using your system's 'file manager'
>
> Et voil??!
>
>
>>> Now, you have an exact illustration and on-screen evidence of what 
>>> is happening!
>
> QED on the code-building, and QED on proving the algorithm!
>
> Thereafter collect the working code (ignoring any side-trips, 
> experiments, or misapprehensions) into a source-code file (document). 
> Then, (having "made it work") you can think about adding loops, 
> splitting functionality, etc (you can "make it better")!
>
> However (at great risk to your sanity)...
>
>
>>> Also, which editor are you using?
>>>
>> Spyder-3.6.6
>
> I know you are climbing the I-must-absorb-enough-Python 
> 'learning-curve', but I recommend that you divert for a moment and 
> take a look at two Spyder features:
>
> [warning: I have long had intentions of reviewing Spyder, but have 
> thus far only perused their web site - so am working from 'promises' 
> (aka "vapor-ware") rather than hard-experience. All due apologies!]
>
>
> 1 Variable Explorer
> - this shows you the contents of each variable in your code, and 
> enables review as the values (should) change. So, it becomes possible 
> to (literally) see when something contains more than one component, 
> when it shouldn't; or to quickly notice if the result is otherwise not 
> what you expected! (without those extra debug-prints)
>
> 2 Debugging
> - this offers (pull down the eponymous top-menu or view web-ref) the 
> ability to pause program execution at any stage and/or to step through 
> the Python code instruction-by-instruction, watching closely for 
> cause-and-effect.
>
> Wonderful stuff. What I wouldn't have given for tools like this, 
> back-when...!
>
>
> The combination of these two facilities offers a powerful alternative 
> mode of attack to the Python REPR approach outlined earlier, depending 
> upon one's preferred approach.
>
> I must admit, coming from the ?good, old days when we planned-out 
> programs - first in flow-charts, and then by hand-writing the code, 
> even on punched-card Coding Sheets; tools such as Spyder offer the 
> opportunity to first 'solve' the entire problem, and then prove it - 
> which feels 'natural' (actually learned/ingrained/beaten into us!), ie 
> the approach you've been taking.
>
> Whereas the REPR, as described, allows one to literally start from 
> nothing and conjure a solution out of 'thin-air' (or perhaps in this 
> case: learn by experimenting, line-by-line).
>
>
> I think you've got the bit between your teeth (if you'll pardon the 
> pun) and must be scenting victory...
>
>
> Web-Refs:
> https://docs.spyder-ide.org/variableexplorer.html
> https://docs.spyder-ide.org/debugging.html

What a great and gracious response.

Thanks to the help from this list, I have achieved success. Here is my code:

> #!/usr/bin/env python3
> # -*- coding: utf-8 -*-
> """
> Created on Fri Oct 11 09:36:30 2019
>
> """
>
> import os
> import glob
> import numpy as np
>
> fileList = []
>
>
> for files in glob.glob("*.log"):
>     fileName, fileExtension = os.path.splitext(files)
>     fileList.append(fileName)
>
> for filename in fileList:
>     data = np.genfromtxt(filename+'.log', usecols=(1), skip_header=27, 
> skip_footer=1, encoding=None)
>     np.savetxt(filename+'-dG', data, fmt='%.15g', header=filename)

Many, many thanks.

-- 
Stephen P. Molnar, Ph.D.
www.molecular-modeling.net
614.312.7528 (c)
Skype:  smolnar1