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

[David L Neil]

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
-- 
Regards =dn