On Sat, Aug 31, 2019 at 2:19 AM Cristian Cocos <cri...@ieee.org> wrote: > > Thank you! Will give the "types" module a whirl. > > Otherwise, the whole idea behind building a rigorous taxonomical hierarchy > ("taxonomy") is to provide a simpler management of the wealth of features > objects have. And that is because entities belonging to the same > taxonomical class ("clade") have common features, and also inherit the > features of the taxonomical parent. A kosher type hierarchy (or class > taxonomy) is thus meant to answer precisely your concern about > entity/object behavior. Now, it may be that this was not the intention of > Python developers when they came up with the breakdown of the class of > objects into types/classes, in which case the term "type" and derivatives > (subtype, supertype etc.) used in this context is nothing but a regrettable > misnomer. Then maybe I should re-direct my quest away from studying the > type hierarchy, toward asking for built-in-object inheritance: Is there a > diagram of built-in-object inheritance available anywhere? >
Even in biology, taxonomy has its limitations. For instance, you might assert that all birds can fly, and therefore that all members of a subclass of birds can fly; but the Emu would like to have a word with you. Or you might posit that all mammals give birth to live young, but then Platypus would give you a taste of its spur. [1] In software design, the same kinds of exceptions do occur. By and large, principles like "anywhere that you could use the superclass, you can equivalently use a subclass of it" will hold true, but there are good reasons to go against them sometimes. So if you're looking for absolute hard-and-fast taxonomic rules about Python types, you won't find them... but you CAN expect things to generally follow rules like LSP. That means that, for instance, any operation valid on an instance of the vanilla 'object' type can be done on literally any object in Python, and anything you can do with the 'type' type can be done with any Python class. Notably, since "type" is a subclass of "object", this means that you can manipulate types the same way that you manipulate anything else. As to a diagram of built-in objects... this might be of some help: https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy It's not fully comprehensive, but it hopefully will have some useful information. Another neat trick is that all types have a __subclasses__() method, so you can sometimes build up your hierarchy that way: >>> LookupError.__subclasses__() [<class 'IndexError'>, <class 'KeyError'>, <class 'encodings.CodecRegistryError'>] Start from 'object' and delve from there. And when you hit 'type' in your exploration, you'll learn something about re-entrant hierarchies and how descriptors work :) ChrisA [1] One valid counter-argument here is that Australia is just plain weird. I've lived here all my life, and it's certainly true. -- https://mail.python.org/mailman/listinfo/python-list