Class Variable Access and Assignment

[Steven D'Aprano]

On Fri, 04 Nov 2005 20:41:31 -0800, Paul Rubin wrote:

> Steven D'Aprano <steve at REMOVETHIScyber.com.au> writes:
>> It also allows you to do something like this:
>> 
>> class ExpertGame(Game):
>>     current_level = 100
> 
>> and then use ExpertGame anywhere you would have used Game with no problems.
> 
> Well, let's say you set, hmm, current_score = 100 instead of current_level.

Right. Because inheriting scores makes so much sense. But that's okay.
Assume I think of some use for inheriting scores and implement this.

> Scores in some games can get pretty large as you get to the higher
> levels, enough so that you start needing long ints, which maybe are
> used elsewhere in your game too, like for the cryptographic signatures
> that authenticate the pieces of treasure in the dungeon.  

Python already converts ints to long automatically, but please, do go on.

> 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.


> 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?

> So now, current_score += 3000 increments the class variable instead of
> creating an instance variable, and whoever maintains your code by then
> now has a very weird bug to track down and fix.

That's a lot of words to say "If ints become mutable when you expect
them to be immutable, things will go badly for you." Well duh.

What exactly is your point? That bugs can happen if the behaviour of your
underlying libraries changes? If list.sort suddenly starts randomizing the
list instead of sorting it, I'll have bugs too. Should I avoid using sort
just in case?


-- 
Steven.