"use strict"

[DL Neil]

On 12/03/19 8:00 AM, Abdur-Rahmaan Janhangeer wrote:
> about the editor part i think yes it'd underline unused variables or
> somewhat similar.

is that the best we can hope for (coupled with type annotations)?


> the problem was that i was reviewing the code, since everything worked (no
> errors but wrong output for sure) it took sometimes to find that var. it
> was like someone telling me there is fish in that lake and i was throwing
> my line trying ...
> just a way to flag those types of vars when needed.


Yes. Such is enormously frustrating, but where does it fit in the wider 
scope of coding in Python? Proportionally?


Once again at risk of tripping over my long, flowing, beard: in the 
(?)good, old days, when every compilation resulted in a pile of 
print-out (and hopefully no syntax errors or typos); we could request a 
list of all of the variables/symbols defined in the code. One still had 
to scan that list manually, and pick-out any inconsistencies, eg 
misspellings!


Which made me think about the Python debugger 
(https://docs.python.org/3/library/debug.html)

[regret: since working with a team that demanded I update/learn/follow 
TDD (Test-driven Development), I haven't (?gone back to) used PDB since 
the time when all of my coding was in Py2!]

If you haven't already, it might be worth a quick shufti. Aspects may 
help you/your colleague!


A debugger will enable you to monitor the values stored in variables - 
but may not be so helpful, in that you must either look at 'everything' 
or first be aware of which variable(s) is/are causing problems. (per my 
'history lesson', above)

There are a variety of Python-compatible debuggers. One may suitably 
cover your need. (https://wiki.python.org/moin/PythonDebuggingTools)


In other threads I've enthused about the learning tools employed in the 
new-ish U.Mich/Coursera Py3 course. One of those tools, which your 
colleague might find helpful, is Philip Guo's Python Tutor 
(http://www.pythontutor.com/).

This tool also allows one to step-through Python code (or run to 'the 
end'), and right beside its 'terminal window', dynamically maintains a 
diagrammatic view of current-values and where they are kept in storage 
(making use of the "frames" within Python's 'innards') - so, also handy 
for noting separations of "scope"...

Trivial example: 
http://www.pythontutor.com/visualize.html#code=a%20%3D%201%0Ab%20%3D%202%0Ac%20%3D%20a%20%2B%20b%0Aprint%28%20f'%7Ba%7D%20%2B%20%7Bb%7D%20%3D%20%7Bc%7D'%20%29%0A&cumulative=false&curInstr=4&heapPrimitives=nevernest&mode=display&origin=opt-frontend.js&py=3&rawInputLstJSON=%5B%5D&textReferences=false
[NB I'm not sure how long this link will live]

Ahah! Showing the global frame/list of variables and their values, 
immediately highlights the situation where an "h" shows-up when we think 
we're using "g".


OTOH it's a tutorial tool - so its use may be more trouble than it is 
worth in the professional environment. So, returning to my (personal) 
comment about PDB. (which was not meant to be at all derisive - every 
tool has its place) My experience (again, personal - if I may), is that 
once 'the guys' tuned me in to TDD, I found that because we were writing 
(and testing) smaller units of code at one time (for later 
assembly/integration into larger units), 'silly mistakes', eg my making 
a typo, became evident much 'earlier' - and when the 
debugging/tracing/testing was so much easier! That said, I can 
immediately see why a 10~20 line function is unlikely to require my 
pulling-out a "big gun" such as PDB - and if it was particularly 
tricky/causing me frustration, such would be easy-enough to drop into 
the PythonTutor tool!


[others may counsel differently - in which case, I'm ready to (re-)learn...]
-- 
Regards =dn