Steven D'Aprano <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
