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
--
https://mail.python.org/mailman/listinfo/python-list
