Behaviour of pop() for dictionaries

[dn]

On 15/06/2021 21.37, BlindAnagram wrote:
> On 15/06/2021 00:11, dn wrote:
>> On 15/06/2021 09.18, BlindAnagram wrote:
>>> On 14/06/2021 20:43, Chris Angelico wrote:
>>>> On Tue, Jun 15, 2021 at 5:41 AM BlindAnagram
>> ...
> I think the difference here is that I know I am going to have to look at
> the documentation for dequeue when I want to use it. For lists, sets and
> dictionaries, I don't expect to look at the documentation and pop()
> seemed a good bet for what I wanted to do.

"What I expect" (aka 'dim/dusty recollection' or 'gut feel') is a good
way to learn - match it with the Python REPL and a couple of experiments
to 'prove' your expectation/recollection. Thereafter there is a far
greater likelihood of "learning" - and remembering-correctly 'next time'...

The other worthy technique in this field is "deliberate learning". Thus,
spending some time studying the docs for the built-ins' functionality
(and experimentation) to obviate the need to look-up that level of
documentation.

Contrary to the learning-practices of 'our day', these days there is a
far lower reliance on memory, in favor of rapid-access to reference
data, eg the Python docs and REPL's help(), etc. Accordingly, the 'bits'
that we might think of as 'minimum knowledge' may be seen as somewhat
"arbitrary".
(actually it is called Curriculum Design, but given that there is no
single application-area for Python there is no single curriculum either)

No matter: we are completely correct, no question - and what would
'they' know anyway?


PS we were also subject to the idea that intelligence/ability was
largely genetic and thus only available in a fixed quantity - either one
is 'good' at something, or not (full stop). These days we know ourselves
(brains) to be more "plastic", and that with sufficient motivation and
effort we can learn 'new stuff', regardless of whether we were 'good at
it' yesterday!


>> I don't know if you are ComSc student or not, but there isn't even
>> consistency at the theoretical level. I first arrived at the concept of
>> "queuing" and "dequeuing" (NB the latter is not the same as the Python
>> Collections module "deque" library) whilst studying Queue Theory in
>> Operations Research. At about the same time, my ComSc studies took me
>> into "stacks".
> 
> My student days are well over (about 60 years over).

Someone with an even longer beard than mine! We could compare walking
sticks...

Oh wait, aren't we talking about Python.

I'm amazed at how stuff from 'history' is recyclable and becomes
applicable to whichever is described as 'today'. Even 'new' things in
computing!

There's always something new to adapt, if not learn...


...

> Yes, but we can still seek consistency where it is possible

Trouble is, there are different ways of looking at 'stuff', and thus
different dimensions of "consistent".

Thus, dict methods try to be consistent to the way a dict behaves.
Whereas being 'consistent' with other collections: sets, lists, strings,
etc; comes second. Oops if not OOPs!


>> Having entered the queue-of-life a long time ago, and shuffling ever
>> closer to 'the end of the line', this memory-challenged 'silver-surfer'
>> prefers to reserve pop() for straightforward stacks and lists, which
>> implies quite enough inconsistency, without trying to convolute my mind
>> to pop()-ing dicts, sets (or 'worse'!).

I still haven't recalled a single occasion when I've used set.pop() or
dict.pop(). Was that because I didn't recall their availability at the
right time, or does my mind simply not see that 'consistency' yours
recognises?
(not that it matters particularly)


>> That said, whether I actually use dict.pop() or not, these 'features'
>> which are consistent in name but not necessarily in arguments or
>> effects, contribute to Python's great flexibility and power! Thank
>> goodness for help() and the Python docs...
> 
> I don't like 'pop's at all since it meant that a valve had exploded on
> the Ferranti Pegasus that was my first encounter with computers.

That does pre-date the prehistoric computers I managed to play-with!

There's apparently one in LON's Science Museum. Don't know if it was
there when I last visited (c.15 years ago) - I do recall their Babbage
implementations and an analog computer (looked like some torture rack)
similar to one that my father used way, way, way-back. Similarly,
considering it/another similar exhibit and talking with our friends
about the 'joys' of using paper tape (and its talent for wrapping itself
around anything and everything, except where you wanted it) and those of
(assembler) programming delays in order to store data on rotating
mag-drums.

Those were the days!
(or maybe not)
-- 
Regards,
=dn