Class Variable Access and Assignment

[Paul Rubin]

Steven D'Aprano <steve at REMOVETHIScyber.com.au> writes:
> > Next you get some performance gain by using gmpy to handle the long int arithmetic,
> 
> Then whatever happens next will be my own stupid fault for prematurely optimising code.

Huh?  There's nothing premature about using gmpy if you need better long int performance.
It was written for a reason, after all.

> > and guess what?  Eventually a version of your game comes along
> > that enables the postulated (but not yet implemented) mutable int
> > feature of gmpy for yet more performance gains.
> 
> This would be using Python3 or Python4?

No, it would be a gmpy feature, not a Python feature.  So it could be
used with any version of Python.  

> What exactly is your point? That bugs can happen if the behaviour of your
> underlying libraries changes? 

That your initialization scheme is brittle--the idea of data
abstraction is being able to change object behaviors -without- making
surprising bugs like that one.  You don't even need the contrived gmpy
example.  You might replace the level number with, say, a list of
levels that have been visited.

I don't think the culprit is the mutable/immutable distinction +=
uses, though that is certainly somewhat odd.  I think Antoon is on the
right track: namespaces in Python live in sort of a ghetto unbecoming
of how the Zen list describes them as a "honking great idea".  These
things we call variables are boxed objects where the namespace is the
box.  So having x+=y resolve x to a slot in a namespace before
incrementing that same slot by y, maybe better uses the notion of
namespaces than what happens now.  I'm too sleepy to see for sure
whether it gets rid of the mutable/immutable weirdness.