By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,396 Members | 1,091 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,396 IT Pros & Developers. It's quick & easy.

Assigning to self.__class__

P: n/a
I have some places in pyparsing where I've found that the most
straightforward way to adjust an instance's behavior is to change its class.
I do this by assigning to self.__class__, and things all work fine.

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

-- Paul
Jan 26 '06 #1
Share this Question
Share on Google+
4 Replies

P: n/a
Paul McGuire wrote:
I have some places in pyparsing where I've found that the most
straightforward way to adjust an instance's behavior is to change its class.
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
objects,
AFAIK, yes.
or am I taking advantage of a fortuitous accident, which may get
undone at a future time?


It's certainly not a fortuitous accident.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Jan 26 '06 #2

P: n/a
bruno at modulix wrote:
Paul McGuire wrote:
or am I taking advantage of a fortuitous accident, which may get
undone at a future time?


It's certainly not a fortuitous accident.


And even the (printed) cookbook has examples which assign to
self.__class__... I guess this means this feature isn't going to go away
soo. ;-)

--- Heiko.
Jan 26 '06 #3

P: n/a
Heiko Wundram <mo*******@bit-bukket.org> wrote:
bruno at modulix wrote:
Paul McGuire wrote:
or am I taking advantage of a fortuitous accident, which may get
undone at a future time?


It's certainly not a fortuitous accident.


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!-)
Alex
Jan 26 '06 #4

P: n/a

"Paul McGuire" <pt***@austin.rr._bogus_.com> wrote in message
news:_G***************@tornado.texas.rr.com...
I have some places in pyparsing where I've found that the most
straightforward way to adjust an instance's behavior is to change its
class.
I do this by assigning to self.__class__, and things all work fine.

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


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

Terry J. Reedy

Jan 26 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.