(Converting to use of __new__ is not an option - in one case, the change is
temporary, and before the end of the function, I change it back again.)
Any comments on this practice? Is this intended capability for Python
objects, or am I taking advantage of a fortuitous accident, which may get
undone at a future time?
Hooray ! You've just (re)discovered the state pattern... for which the
most stupid simple implementation in Python is to :
>(snip) assigning to self.__class__, (snip)
> Any comments on this practice?
It can be very confusing for newbies and peoples having no experience
with *dynamic* languages, and I guess control-freaks and
static-typing-addicts would runaway screaming. But I like it anyway !-)
> Is this intended capability for Python
> or am I taking advantage of a fortuitous accident, which may get
> undone at a future time?
It's certainly not a fortuitous accident.
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'on...@xiludom.gro'.split('@')])"
And even the (printed) cookbook has examples which assign to
self.__class__... I guess this means this feature isn't going to go away
Hmmm, I'm the main decision-maker for what goes in the printed cookbook,
but it's Guido who decides what stays or goes in the language, and it's
not as if we always agree (though I will admit that when we disagree it
later usually turns out he's right, but that's another issue;-). Still,
in this case I don't think we disagree!-)
Very little if any of the new class stuff is accidental. As I remember,
.__class__ was originally read-only and was intentionally changed when
practical use cases for rewriting it were developed and presented with a
request for change. Though I could be wrong, I would comfortably use this
Terry J. Reedy