Wow, I turned my back to attend to $job and this conversation has
'exploded' (>80 msgs)!
TLDR;
With apologies, I started to reply to your reply, but then added 'bits'
as I read the conversation thereafter. The result (below) is a messy
hodge-podge, for which I can only apologise (as I don't have more
spare-time to be able to 'fix it' and edit it into some semblance of
proper order). May I suggest a first quick-read to pick-up the
'highlights', and then re-reading in order to make sense of the
cross-references? I regret the appearance of circling-back between topics...
On 10/12/19 9:45 pm, R.Wieser wrote:
...
Than again, I normally camel-case my variable and function names (to make
them stand out from the build-in commands), as I normally do not use editors
with syntax highlighting.
...
:-) Always start with a descriptive* name for the variable, regardless of if
it is a compounded one or not. As said, the type prefix is just a
reminder.
Remember that PEP-8 is (only?) applied to code submitted for inclusion
in the Python Standard Library. It's wider application is less
prescriptive (although many in-house style manuals take an
embrace-and-extend approach).
Bottom-line (IMHO):
- if you are coding by yourself and only for yourself, you make your own
'rules'!
- if you are working with others, you (all) come up with 'the rules' -
one of which may be that you allow 'the other guy' to make his own
rules, whilst (s)he does the same for you - and simply work-around that
with your own (and, one assumes, v-v)
- if the organisation/team already has 'rules', then you adapt to the
group mores...
Have you come across the bit where Guido (I think?) talks about "the
hobgoblin" of over-applying 'rules'? To which the 'Zen of Python' adds
(the joke) "unless you're Dutch".
The topic of naming-standards is a massive time-sink/hobgoblin (see also
- using tabs or spaces to indent, and 'how many spaces')...
(see also: which car is 'best', which language is 'best', which team...,
which super-hero..., do you really love me? does my bum look big in this...)
That said, there's enough to learn when taking-on a new language,
without 'sweating the small stuff' ("cognitive load"). So, if it helps
you to use VS Coding Standards right now, just do it. Later, as you come
to understand more of the 'philosophies' behind Python, you will/may
learn/adapt (see also, 'working with others', above).
*though not /too/ descriptive. Languages which can easily have
40-character names for variables, functions and such are simply the pits,
especially when they start to differ only for a single/few character(s)
somewhere in the middle. :-(
Surely it is unlikely that all 40-characters are necessary to
communicate meaning!? Even in Welsh?Tamil?Dutch?German?
That said, it is *so* easy with modern text editors to make universal
changes (an error-laden task filled with so much peril it was
strenuously-avoided in the ?good, old, days) - which ease applies as
much to variableNMs as it does to interpreting what tab-to-indent
means/is to mean for this module!
In other words, I play as fast-and-loose as does Python (per earlier
comment).
rudy = Man( etc ) #rudy probably does have class, in this instance
You almost owed me a new keyboard there. :-p
Normally my lame jokes are greeted with a groan, so I'll take that as a
compliment (regardless of how it was intended - I'm that desperate!)
Which brings me to a few points, noted throughout the conversation.
Whereas I do offer training (not Python), hold a qualification in the
field (specifically vocational training/andragogy), and have a research
interest in Cognitive Psychology (yeah, yeah, blah, blah, big deal...)
there will be very few others, similar, who are also (active) members of
this list. Expecting high-quality 'training materials' as responses is
probably asking 'a bit much'...
We do have folk (on the list) who are actively developing the language,
others who use the language professionally and every-day, and still
more, less specialised, right ?down to 'mere' hobbyists who only get to
talk-Python at (some) weekends. Answers reflect that. However, a scan of
(names frequently appearing in) the archives will soon reveal 'much'!
In case of misunderstanding:
There is no-one (to my knowledge) who is paid to be 'here'. All
contributions are voluntary and provided out of people's 'free time'. It
is not a manufacturer's 'support site'!
The best way to receive help with coding (as has been said) is to
copy-paste *your* problematic code into a post. This allows interested
parties to easily reproduce the problem (or not). It also ensures that
responses are as specific as possible by providing 'focus'!
It also pays to continue the copy-paste-result pattern when replying to
advice: 'I've tried it, and 'this' is what happened' - yet I understood
you to say 'that' should...' Such not only ensures/contributes to
ensuring that both/all understand the problem and are discussing the
'same' thing; but incidentally show that you have respected the person's
contribution, have paid due attention, and have tried/failed it...
If any response appears incomplete or 'insufficient', then is it
incumbent upon you to research and experiment further, or should the
person who has already given-up his/her time do more/'do a better job'?
(another rhetorical question)
As a reference-point: Not so long ago, I was told, by folk on this list,
that what I expected/requested of a Python library was not 'right', ie
not congruent with the thinking of the code's authors. I also
mis-interpreted words within the explanations. Thus my 'experience' and
understanding was tripping-up my Python-comprehension, and it took a
couple of 'rounds' before people zero-ed in on exactly why - and thus
how to pound 'understanding' through my thick skull. In the end I
realised that the library was not (?good enough) going to do what I
thought it would?should, and I could either beat my head against its
'brick wall' or I could 'go elsewhere' (which I did). None of which
stopped me from learning, nor did it deny the kindness of others
prepared to 'set me right'...
I was amused to be reminded of (your recollection) the 'rules for
debugging' but its superficiality does not (necessarily) apply - and you
knew that!!! Given Python's many allusions to the "Monty Python"
comedies, you should have no trouble finding the source when I quote
that you are "a very naughty boy"!
In many cases, within the Python environment (and philosophy),
extracting a minimal version of the problem and solving that, may even
remove/ameliorate the effect of 'by-products' and 'unfortunate'
combinations or assumptions (on my part). Debugging a dynamic language,
cf FORTRAN, et al; is a quite 'different ball-game'!
On which topic, have you discovered the Python REPL? Whilst we (appear
to be) are talking 'debugging', there is no equivalent anodyne (that I
have come-across) in the compiled world, and I frequently use it when
first coding/designing something (cf debugging-mode) to assure my
'mental model'. It offers the opportunity to code a couple of lines,
particularly when using a construct for the very first time, and to
'see' the results immediately. In other words, to ensure that our
understanding of 'what the books says' is the same as the way Python
'sees it'. So, those few lines of creating a class, instantiating it,
and then deleting (one/other/both)... Really easy (can even copy-paste
'the answer' into one's editor), and an immensely valuable learning (and
'reminding') tool!
You may also enjoy the facilities of Philip Gao's web-based
demonstration at http://pythontutor.com/ (be aware, its objectives are
to 'show' what happens inside 'the computer', I won't guarantee that any
'demonstration' of del() or the Garbage Collector are authoritative!)
:-) The normal newbie progression, off of which I'm in phase #1. Having a
working program (riddeled with debugging output) is still (way) more
important than having the best code I'm afraid. But reading about how
others handle it definitily makes it easier for me to progress.
I like to think of (at least) three stages in learning Python:
'apprentice', 'journeyman', and 'master'. (which, coincidentally, even
though I've changed from mine to adopt one of their choices of
terminology are the names of a series of Python-training books)
The words/titles are something of an outline of the learning process. As
an 'apprentice', and noticing that Python often 'does things
differently' when compared with other languages-I-have-known, it seemed
easier to take certain statements 'on faith'. Later to re-visit topics
as a 'journeyman' (and presumably, again, as a 'master' - am not sure
that I could claim such lofty heights!). The opposite of solving a
problem by 'peeling the onion' - putting successive layers on the onion,
one after the other; if you will.
In this way, we learn a 'little bit' about each facility, and later
learn 'a bit more', and later..., until we (hopefully) achieve mastery.
In ComSc we would call this a "width-first" or "breadth-first" approach!
In Cognitive Psychology we talk of creating a framework or "map" in your
mind - of how things work by fitting-together. We best construct these
frameworks by starting from 'known knowledge' and bolting-on
(bite-sized) chunks of new-knowledge.
However, (why is there always a "but"?) sometimes the existing framework
is inappropriate, eg both a car and a go-kart have four wheels, but if
you knew a lot about cars and started from a car-chassis, you would soon
decide that was the wrong 'framework' from which to learn to build your
first go-kart! Accordingly, (and this is *really* difficult) talking
(elsewhere) of being prepared to 'take on faith', some new-learning, in
the expectation of better-seeing how the 'chunks' fit-together later, as
one gains experience (in Python), becomes a 'journeyman'/'master'...
Perhaps some of the 'heat' in this conversation have been caused by
taking a depth-first approach on a very, very, narrow (and highly
specialised) topic? Way-back, I commented that the conversation
contained some useful information for 'us all' - thinking 'apprentice'
and 'journeyman' (back then); but since then, many of the contributions
have come from 'masters' - and were certainly close to sailing right
over my head/abilities in Python!
Whilst it is *not* my intention to denigrate anything said, I take great
comfort in knowing that the likelihood that I'll ever have to notice the
difference between the time del() is executed and the
garbage-collector's effect, is so small, as to be almost irrelevant.
(see elsewhere 'fast and loose')
Um, that is, until it is!
Meantime, I luxuriate in my ignorance, keep breathing, and reach for
another square of chocolate...
Back to 'debugging': Yes, adding 'more code' in an attempt to 'solve' a
problem certainly was contra-indicated - the 'target' kept changing, and
the number of balls to be 'juggled' kept increasing.
However, the advice about considering the use of a "Context Manager"
("with") was not 'adding', but (at worst!) 'replacing' (see 'frameworks'
comment).
It is *very* unfortunate that almost every example of the use of Context
Managers features file-management, and few, if any, other applications.
Context Managers come into their own when there is an 'open' situation
which must be matched by some 'close' (terminology is "entry" and
"exit"), hence the 'file' example (assumed "existing knowledge"!).
However, these are serial events (first I open the file, then I process
it, then I close it); so what's the big deal? The problem comes when
something goes wrong! If the file was not actually opened, that's
relatively easily dealt-with, but if it was, it should/must be closed -
regardless of any error-experienced. Dealing with that sort of thing
becomes relatively-complex and thus error-prone.
I'm enthusiastic about Context Managers because I do a lot of work with
RDBMS-es. Here there are two layers of problem-possibility: in first
gaining access to the RDBMS itself, and secondly dealing with the actual
query and its "cursor" (result)...
The objective of a Context Manager then, is to relieve some of this
'overhead' and 'boiler-plate' - the Exit code will be executed
auto-magically, and regardless of success/error (assuming Python is
still running). Well, I don't know about you, but that's good news to
this lazy-boy!
In your situation: the "Entry" point is when you decide it is time to
look at the GPIO pin's state. The "Exit" is when you've done 'whatever'
with that value (and don't wish it to be used again until there's a
state-change, time passes, or whatever). The 'context' is the process
you wish carried-out, in-between, as a result of/utilising the GPIO
pin's reading. In this context (hah!) doing something overt in
__exit__() is *likely* to be more successful/reliable/'pythonic' than
passively relying upon del().
In other words, this is a (Python) tool-for-the-job - and thus worth the
investment of your time. Yes, you could use a 'hammer' on a screw, but
the reliability of the end-result would be better if a screw-driver were
the tool employed - AND likely easier, AND less frustrating! (see
earlier 'warning' about 'translating' between languages)
So, if it is the correct tool for this job (the one that you want to
achieve), then there is little to be gained by limiting your view to
that of the code you are currently debugging. (particularly if you wrote
it, as you self-describe, as an 'apprentice'!)
>> Expanding on 'names' and del(): the first point is that there is seldom
>> much to be gained by using del(), ie becoming your own 'garbage
>> collector'.
As mentioned earlier (and confirmed, since), conflating del() and
garbage-collection is not strictly accurate; but it will 'do' for us
proto-masters (and likely for many 'masters' too)!
Am wondering what is to be gained by trying to become a 'master' in such
a narrow portion of Python ("depth first"), when as an 'apprentice',
time might better be spent learning (something of) the 'breadth' of
Python? (rhetorical question - answer is 'none of my business'/you
should do/think what you want to do...)
In my case deleting the instance was needed to release its hold on something
that was taken when the instance was initialised (in my case a GPIO pin on a
Raspberry Pi). I did not even think of garbage collection.
In talking so-specifically about del(), etc, have we 'disappeared down a
rabbit hole' and not actually addressed this question? Does deleting the
instance/class release the GPIO pin, or is there another/a better way?
I haven't started to 'play' with my recently-purchased SoC, but forty
years after constructing my own Motorola D2 Kit (which gave me a
'computer' with binary inputs and bar-LED o/p), and much wanting to get
back to systems-on-a-chip or "microcomputers", even if (only) as a
hobby, I'm finally 'getting there'...
So, I'd like to request further clarification:
- do we need to 'release' (reset, or whatever) the GPIO pin, or
- are we talking about 'disposing of' a variable which represents/holds
the GPIO pin's value (as it was when 'read') - presumably in preparation
to reading it again/next time?
There is also a major implication here (which has been addressed as the
different behavior of del()/GC within different Python implementations).
Which Python are you using, under which OpSys - and if you are talking
about developing in Python on a desktop, will that carry forward to the
SoC or are there (material) differences in Python and/or OpSys?
I've been noting various contributions to this list, on topics related
to Python on/for SoCs. One of which is that there is a (at least one)
specialised version (?sub-set) of Python for SoCs. NB I haven't
read/done anything much further than that! You may like/need to
investigate...
Given that we are no longer talking about "How do I import a class...",
perhaps starting a new post with significant key-words in the Subject:
might encourage SoC-experienced folk to offer more knowledgeable
assistance...
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
