An "Object" class?

[Cristian Cocos]

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 <tjreedy at 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