Python3 - How do I import a class from another file

[DL Neil]

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