2012-03-09 9 views
6

Tengo entendido que, dado que la unificación de tipo/clase cada valor es de un tipo que deriva de object. Sin embargo, no puedo encontrar la confirmación absoluta de esto en los documentos. Si bien es lógico que isinstance(anything, object) siempre debe ser True, también podría imaginar que hay casos de borde heredados en la base de código de Python 2. ¿Alguien sabe de un ejemplo donde isinstance(value, object) es noTrue?¿Existe algún valor en Python para el cual isinstance (value, object) no sea True?

Contexto: como parte de una jerarquía de tipos que estoy diseñando, existe un tipo omnipresente Alpha para el que deseo isinstance(obj, Alpha) siempre devolver True. Estoy pensando que en Python 2.6+ ABCMeta.register(object) debería hacer el truco, pero quiero estar seguro.

EDITAR: Por el bien de la posteridad, ABCMeta.register(object) no funcionará (pruébelo). Ethan Furman ofrece una solución alternativa para este caso en su respuesta a continuación.

+0

Todo es una instancia de 'object'. Hay un truco en el nivel C para hacer que incluso 'tipo (objeto)' sea una instancia de objeto. No tengo una referencia en este momento, pero hubo una publicación de blog en algún momento en los últimos seis meses sobre esto. – agf

Respuesta

1

Es posible crear clases en código que no sea de Python (C, por ejemplo) que no se derivan de object.

Usted debe ser capaz de lograr lo que quiere mediante la adición de __subclasshook__ a su Alpha:

--> import abc 
--> class Test(object): 
... __metaclass__ = abc.ABCMeta 
... @classmethod 
... def __subclasshook__(cls, C): 
...  return True 
... 
--> isinstance(dict(), Test) 
True 
--> isinstance(42, Test) 
True 
--> isinstance(0.59, Test) 
True 
--> class old_style: 
...  pass 
... 
--> isinstance(old_style(), Test) 
True 
+0

Hrm .. pero cualquier tipo de pitón puro siempre se derivará del objeto? Eso podría ser suficiente, siempre y cuando también sea cierto para los módulos C de biblioteca de uso común/estándar (cStringIO, cDecimal, etc.) – maaku

+0

A menos que sigan usando las antiguas clases de estilo, pero si esa distinción no es importante, su '__subclasshook__ 'puede ignorarlo (como lo hace el ejemplo). –

+0

¡Impresionante! Esa parece la solución ideal para 'Alpha'. Gracias Ethan! – maaku

0

En 2.x, las clases definidas por el usuario (y algunas clases stdlib) no se derivan de objeto por defecto . Esto está arreglado en 3.x.

+0

Mayby ¿eso es lo que maaku quiere decir con "desde la unificación tipo/clase"? – WolframH

+0

@ Wolfram H: cada * literal * es una instancia de objeto. Todavía (en 2.x) es posible crear clases cuyas instancias no sean instancias de objeto. –

Cuestiones relacionadas