Thank you! I can see that the taxonomy of built-in classes (i.e. the subclass/superclass relations) is not very developed. At the very least I would have loved to see stuff such as int declared as a subClass/subType of float and the like--that is, a class taxonomy in tune with standard mathematical practice, but I am guessing that mathematical kosher-ness had to take a back seat to implementational concerns.
Neither does the numbers package bring any order or clarity into this; take for example the following sentence from the standard type hierarchy ( https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy): "There are two types of integers [numbers.Integral]: Integers (int) ... [and] Booleans (bool)" I, for one, cannot help but read this as a subtype declaration, which appears to be the wrong construal. For one, I am not sure that numbers.Integral is a type that is returned by the type() function, regardless of the input argument. Furthermore, it looks to me that no instance of the int type is an instance of the numbers.Integral type (and that is based on the fact that type.mro() function applied to some integer does not list numbers.Integral among the returned values (although this may also be a consequence of the fact that type() never returns numbers.Integral)). Anyway, I am looking forward to your correcting any of the above assertions. C On Tue, Aug 27, 2019 at 5:00 PM Terry Reedy <tjre...@udel.edu> wrote: > On 8/27/2019 2:19 PM, Cristian Cocos wrote: > > Thank you! What would be the names of the *class *class, > > and of the *function *class please? > > Use type(ob) to get the internal name of the class of an object. > Built-in classes that users may need to call in python code are bound to > the same name in __builtins__, as if __builtins__ were build with class > statements. but many are not. > > >>> type(object) > <class 'type'> > >>> type(type) > <class 'type'> > >>> type(int) > <class 'type'> > >>> type(abs) # built-in function > <class 'builtin_function_or_method'> > > Users can usefully call 'type' but not 'builtin_function_or_method'. > > >>> def(f): pass > > >>> type(f) # User-defined function. > <class 'function'> > >>> l = lambda: None # Equivalent lambda expression. > >>> type(l) > <class 'function'> > > Creating a function by calling 'function' instead of using 'def' or > 'lambda' is a super expert endeaver, and the details are CPython > specific and subject to change in any version. > > >>> type(list.__add__) > <class 'wrapper_descriptor'> > >>> type(list.append) > <class 'method_descriptor'> > >>> for k, v in vars(list).items(): print(k, type(v)) > # 36 lines. > > To see super classes of a class, use type.mro(cls). The returned list > always begins with cls and ends with 'object' > > >>> mro = type.mro > >>> mro(object) > [<class 'object'>] # As Chris said, baseclass has no superclass. > >>> mro(type) > [<class 'type'>, <class 'object'>] > >>> mro(list) > [<class 'list'>, <class 'object'>] > # Nearly all built-in classes return [cls, 'object']. > >>> mro(bool) > [<class 'bool'>, <class 'int'>, <class 'object'>] > # The only exception I can think of. > > -- > Terry Jan Reedy > > -- > https://mail.python.org/mailman/listinfo/python-list > -- "People think that I must be a very strange person. This is not correct. I have the heart of a small boy. It is in a glass jar on my desk." -- Stephen King -- https://mail.python.org/mailman/listinfo/python-list
