我有一个由外部库提供给我的类。我创建了这个类的一个子类。我也有一个原始类的实例。

我现在想将此实例转换为我的子类的一个实例，而不更改该实例已有的任何属性(我的子类将覆盖的属性除外)。

以下解决方案似乎有效。

# This class comes from an external library. I don't (want) to control
# it, and I want to be open to changes that get made to the class
# by the library provider.
class Programmer(object):
    def __init__(self,name):
        self._name = name

    def greet(self):
        print "Hi, my name is %s." % self._name

    def hard_work(self):
        print "The garbage collector will take care of everything."

# This is my subclass.
class C_Programmer(Programmer):
    def __init__(self, *args, **kwargs):
        super(C_Programmer,self).__init__(*args, **kwargs)
        self.learn_C()

    def learn_C(self):
        self._knowledge = ["malloc","free","pointer arithmetic","curly braces"]

    def hard_work(self):
        print "I'll have to remember " + " and ".join(self._knowledge) + "."

    # The questionable thing: Reclassing a programmer.
    @classmethod
    def teach_C(cls, programmer):
        programmer.__class__ = cls # <-- do I really want to do this?
        programmer.learn_C()


joel = C_Programmer("Joel")
joel.greet()
joel.hard_work()
#>Hi, my name is Joel.
#>I'll have to remember malloc and free and pointer arithmetic and curly braces.

jeff = Programmer("Jeff")

# We (or someone else) makes changes to the instance. The reclassing shouldn't
# overwrite these.
jeff._name = "Jeff A" 

jeff.greet()
jeff.hard_work()
#>Hi, my name is Jeff A.
#>The garbage collector will take care of everything.

# Let magic happen.
C_Programmer.teach_C(jeff)

jeff.greet()
jeff.hard_work()
#>Hi, my name is Jeff A.
#>I'll have to remember malloc and free and pointer arithmetic and curly braces.

但是，我不相信这个解决方案不包含任何我没有想到的警告(对不起，三重否定)，特别是因为重新分配神奇的 __class__ 只是不感觉对。即使这样可行，我也情不自禁地觉得应该有一种更 Python 的方式来做到这一点。

有吗？

编辑:感谢大家的回答。这是我从他们那里得到的:

• 虽然通过分配给 __class__ 来重新分类实例的想法不是一个广泛使用的习惯用法，但大多数答案(在撰写本文时为 6 个中的 4 个)认为它是一种有效的方法。一个答案(来自 ojrac)说它“乍一看很奇怪”，我同意(这是提出这个问题的原因)。只有一个答案(由 Jason Baker 提出；有两个正面评论和投票)强烈劝阻我不要这样做，但是这样做是基于示例用例而不是一般技术。

• 没有一个答案，无论是否正面，都发现此方法存在实际技术问题。一个小异常(exception)是 jls，他提到要提防旧式类(这很可能是真的)和 C 扩展。我认为这种新风格的类感知 C 扩展应该和 Python 本身一样好(假设后者是正确的)，但如果你不同意，请继续给出答案。

关于这有多像pythonic的问题，有一些肯定的答案，但没有给出真正的理由。看看 Zen (import this)，我想在这种情况下最重要的规则是“显式优于隐式”。不过，我不确定这条规则是支持还是反对以这种方式重新分类。

• 使用 {has,get,set}attr 似乎更明确，因为我们明确地对对象进行更改而不是使用魔法。

• 使用 __class__ = newclass 似乎更明确，因为我们明确地说“这现在是类 'newclass' 的对象，期待不同的行为”，而不是默默地改变属性，但让用户对象认为他们正在处理旧类的常规对象。

总结:从技术角度来看，方法似乎还可以； pythonicity问题仍然没有答案，偏向于"is"。

我接受了 Martin Geisler 的回答，因为 Mercurial 插件示例非常强大(也因为它回答了一个我什至还没有问过自己的问题)。但是，如果对 pythonicity 问题有任何争论，我仍然想听听。到目前为止，谢谢。

附:实际用例是一个 UI 数据控件对象，在运行时需要增加额外的功能。但是，这个问题是非常笼统的。

最佳答案

像这样的重新分类实例在 Mercurial 中完成。 (分布式修订控制系统)当扩展(插件)想要更改代表本地存储库的对象时。该对象称为repo，最初是一个localrepo 实例。它依次传递给每个扩展，并且在需要时，扩展将定义一个新类，它是 repo.__class__ 的子类和 change repo 的类 到这个新的子类!

看起来 like this在代码中:

def reposetup(ui, repo):
    # ...

    class bookmark_repo(repo.__class__): 
        def rollback(self):
            if os.path.exists(self.join('undo.bookmarks')):
                util.rename(self.join('undo.bookmarks'), self.join('bookmarks'))
            return super(bookmark_repo, self).rollback() 

        # ...

    repo.__class__ = bookmark_repo 

扩展(我从书签扩展中获取代码)定义了一个名为 reposetup 的模块级函数。 Mercurial 将在初始化扩展时调用它并传递 ui(用户界面)和 repo(存储库)参数。

然后，该函数定义了 repo 恰好是任何类的子类。 不简单地继承 localrepo 因为扩展需要能够相互扩展。因此，如果第一个扩展将 repo.__class__ 更改为 foo_repo，则下一个扩展应该将 repo.__class__ 更改为 foo_repo<> 而不仅仅是 localrepo 的子类。最后，该函数更改了 instanceø 的类，就像您在代码中所做的那样。

我希望这段代码可以证明该语言功能的合法使用。我想这是我见过它在野外使用的唯一地方。

关于subclass - 在 Python 中重新分类实例，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/990758/