Python's object system suffers from the same ailments that Python itself does. It's an amalgamation of various hacks, some obviously inspired by Common Lisp [1], others made up on the spot in order to make everything "fit" together.
In order to best see this, browse CPython's source and find how metaclasses are implemented. Then imagine what you would have to do if you wanted to radically change Python's object system. Contrast with the Common Lisp MOP.
[1] Here is Guido talking about Python's metaobject protocol. Taking into account everything it lacks and how it's implemented, it's not really a metaobject protocol in the CLOS sense, but it's enlightening to read GvR's description of his "aha!" moments in the slides -- which he came upon when he read "The Art of the Metaobject Protocol" -- and then realize that he simply picked very few of the ideas from it whilst completely missing the essence:
http://laser.inf.ethz.ch/2012/slides/vanRossum/laser-mop.pdf
So yes, Python has metaclasses but metaclasses are only ~5% of what makes CLOS (and AMOP) iconoclastic. For the rest, read "The Art of the Metaobject Protocol" [2]. This should convince you that Python is really nothing like Lisp and the philosophy of metaprogramming that Lisp espouses is dumbed down and made pretty much powerless (in a similar way, interactive programming) in Python.
[2] https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Prot...
The canonical implementation (PCL) was written in pre-ANSI CL without CLOS. There's a number of things that are difficult there, but can't put my finger on any related to bootstrapping.
https://en.wikipedia.org/wiki/Common_Lisp_Object_System
Besides Google, I find Wikipedia is often helpful when finding acronym definitions as well. In this particular case, probably adding "Lisp" to your Google search would have helped, but if you didn't know it was limited to that domain, it's understandable that you didn't include it.
This is a persistent myth. CLOS is built in to the language.
The original first CLOS implementation called PCL (Portable CommonLoops) was written in 100% Common Lisp with very little implementation specific CL code. PCL was a library which ran on at least 15 different Common Lisp implementations.
What really is a myth that it's (only) macros. That CLOS implementation is a complex library written as data types, functions, macros, ... and which was bootstrapped to be partly written in itself using classes, method, generic functions, ...
See for example: https://github.com/binghe/PCL
Really? Indeed, if you search for just "CLOS" Google doesn't find it. Duckduckgo on the other hand, gives it in the 3rd link.
Lua and Ruby I fail to see how they are in any way lisp-y.
Lua: Simple, minimal syntax which is consistent (unlike Python), multiparadigm, designed around one core datastructure, metatables/metamethods, metaprogramming is encouraged, has environments.
hy 0.11.1 using CPython(default) 3.5.3 on Linux
=> (cons 1 '(2 3))
(1 2 3)
hy 0.15.0 using CPython(default) 2.7.13 on Linux
=> (cons 1 '(2 3))
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/hy/importer.py", line 199, in hy_eval
return eval(ast_compile(expr, "<eval>", "eval"), namespace)
File "<eval>", line 1, in <module>
NameError: name 'cons' is not defined
Lua is a Lisp-lite, Ruby maybe a Lisp-lite, Python? No way, I'd go as far as say that Python is antithetical to the Lisp philosophy and yes, I know Norvig has claimed something similar in the past. It's still inaccurate and wrong. In an interview, Norvig pretty much admitted that popular appeal is more important to him than the inherent superiority [which he of course acknowledges] of the philosophy behind Lisp.