for convenience

[dn]

On 23/03/2022 09.23, Paul St George wrote:
> On 21/03/2022 18.04, dn wrote:
> 
>> On 22/03/2022 10.17, Chris Angelico wrote:
>>> On Tue, 22 Mar 2022 at 08:13, Paul St George <email at paulstgeorge.com <https://mail.python.org/mailman/listinfo/python-list>> wrote:
>>>>
>>>>
>>>> When I am writing code, I often do things like this:
>>>>
>>>> context = bpy.context  # convenience
>>>>
>>>> then whenever I need bpy.context, I only need to write context
>>>>
>>>>
>>>> Here’s my question:
>>>>
>>>> When I forget to use the convenient shorter form
>>>>
>>>> why is bpy.context not interpreted as bpy.bpy.context?
>>>>
>>>
>>> I don't understand the question. When you do that "for convenience"
>>> assignment, what you're doing is creating a local variable named
>>> "context" which refers to the same thing that bpy.context does (or did
>>> at the time of the assignment, but presumably you only do this when
>>> bpy.context won't get reassigned). It has no effect on any other name.
>>> There's no magic happening here - it's just assignment to the name
>>> context, like anything else.
>>>
>>> What are you expecting to happen here?
>>
>>
>> It's the way Python works.
>>
>> try:
>>
>> context = bpy.context  # convenience
>> print( id(context), id(bpy.context) )
>>
>> Remember that the 'relationship' between the two is established at
>> run-time and at the data/address 'level' - and not at compile-time. Thus
>> "context" points to a memory location, and does not 'stand for'
>> "bpy.context" anywhere other than in your mind.
>>
>> (which is why we often need to use a copy() when we want 'separate data'
>> - see also the 'counters' Python uses to manage "garbage collection")
>>
>> -- 
>> Regards,
>> =dn
> 
> 
> Thanks dn,
> I did exactly as you suggested.
> 
> import bpy
> 
> context = bpy.context  # convenience variable
> print( id(context), id(bpy.context) )
> 
> 4932508928 4932508928
> 
> The two are the same, and that makes it crystal clear. And, as a bonus you have explained a use of copy().
> 
> —
> Thanks,
> Paul


and thank you - it is refreshing, if not enervating, to receive feedback
on efforts-expended!

You will also notice, that now you understand the id() stuff, the
tag-team effect between @Chris and I (which we have often played, albeit
not by-design), now makes sense as an whole (if you didn't quite follow,
earlier).


My research-topic is Cognitive Psychology (how we learn - albeit not
usually in Python). I found this conversation useful, and may well apply
it as an example (with your permission, and suitably anonymised) - one
doesn't need to be a 'computer person' to follow the logic and thus
realise the dissonance!

While learning (this part of) Python and adding to 'previous
experience', you formed a "mental-model" of how things work (just as we
all do). However, when it came time to implement this knowledge:

- you created a 'situation'
- (all) things didn't 'work' (which also required realisation)
- you analysed and rationalised (but noted inconsistency)
- you asked a question (which many of us quickly understood)
- you've learned/corrected


The 'issue' is *not* a fault on your part, nor (necessarily) a lack of
learning or a lack of effort. So, no criticism from me!

The (under-lying) lesson, is that we (as trainers, but with application
to all helpers, pair-programmers, mentors, documentation-writers, et al
- working with less-experienced colleagues) shouldn't spout a whole load
of 'facts', 'rules', and formulae/s - which we expect to be committed to
memory. We need to help form a 'correct' mental-model ("correct" being
defined by the Python interpreter and 'the Python gods' who build it -
big "thank you" to them!).

Accordingly, my criticism of tests/exams which require recitation of
facts ("parroting"), compared with "mastery" (can you actually DO what
is being asked). More importantly, and finally getting to the point:
'tests' should be defined to reveal these (personal) 'quirks' of
learning/understanding, which led to a 'faulty' mental-model!

Your rationale made sense, was logical and understandable. How are you
to know that Python deems it 'wrong'? (until a 'test' shows you!)

The 'interest' should not be on the people who, and all the 'answers'
which, were 'correct'. What is more informative, is why someone (aside
from guessing, ie intelligent, reasonable, after learning the material,
exerting effort...) got it 'wrong' - but thought his/her path was true!
-- 
Regards,
=dn