For efficiency purposes, the MicroPython MRO doesn't match CPython, let alone support overriding it with class.mro().
https://docs.micropython.org/en/latest/genrst/core_language.html#method-resolution-order-mro-is-not-compliant-with-cpython

So perhaps fixing the MRO behaviour first would make sense before adding class.mro(), __bases__, and __mro__. But you'd likely only want to do this for non-microcontroller targets.

i don't think mro order does matter in that case : the point is accessing .__bases__ one way or another.

Doing that with a function seems to have less cost than a dunder and static tuple and also bring more script compatibilty ( .__bases__ is an internal while class.mro() is not and is there since py2 ).

Also maybe that function - when not on MCU target - could check for a user defined .__bases__ filled with the correct mro at runtime : that would help solve the point you noticed.

edit/ i may be biased because i prefer MicroPython mro .

I think if you're going to support them, you should match CPython. The two examples you gave sound to me like they would provide the opposite behaviour -- i.e. custom __bases__ doing what overriding class.mro() is supposed to do, and using class.mro() to get the list of base classes (why not use __bases__).

Could you provide an example use case for how you'd use these three features? Do you want to modify the MRO, inspect the MRO, or inspect the list of base classes? Why do proxy objects need this?

@jimmo external ffi classes or rpc proxy objects that need attr resolution in bases classes for example with C++ see :
https://github.com/pmp-p/panda3d-interrogator/blob/master/build/upanda3d.py#L12690

only inspection of bases / mro is required, as shown here https://github.com/pmp-p/panda3d-interrogator/blob/master/interrogator/uplusplus.py#L285

Full depth would be great but really not critical that's not every day use cases and recursion can solve depth if needed.

another reason for not using .__bases__ is that it is read/write ( unlike __base__ ) and has instant action on MRO. cf #4368

you should match CPython

no i should not. if i need polymorphism and multiple inheritance i use cPython on a supported platform.

Single inheritance is sufficient and is KISS enough in the context (spirit?) of MicroPython. If Python language provides correctly its base functions those can be user implemented in pure Python.

RFC is about what's MISSING for Python compliance not what to ADD.

=> MUST at least provide read only values.
=> MUST NOT be crippled.
=> SHOULD try to do the same as cpython 2/3
=> SHOULD NOT eat rom and ram just for doing the same as cpython 2/3
=> MAY do something different from cpython for good reasons and the sake of a fast and small Python VM.
=> MAY NOT be boring ( please no one take that personnally )

Do i need to sum up (again) what's really missing after 2 years of use ?

• next() // the 3.4 one ( already in but stayed turned off for whatever reason).
• class.mro() // with a readonly .__base__ is enough to reimplement anything more complex port-javascript: check list #4993 and there's a PR Add .__base__ #4368 already addressing a part of that.

• ANY kind of user finalizers ( personnally i'm in favour of JS group finalizers kind ).

sidenote for missing ones that can be reimplemented for user classes (and that's all needed)
but still makes it hard for newcomers so maybe document that.

• vars() // that's the only correct way to access references to internals dicts

as anyone can see it's few !

is it possible to trade execfile() for any of those ? people seems to live fine with compile and exec.
make a poll for that for on a broader audience ?

So perhaps fixing the MRO behaviour first would make sense before adding class.mro(), bases, and mro. But you'd likely only want to do this for non-microcontroller targets.

What are you talking about and why ?

MRO is broken ? please go fix it asap because i guess Python would not work without that.

the cpython __bases__ is not read only and it has side effect it's a cpython internal: and moreover *nobody asked for that here. READ AGAIN

__mro__ ? what's that ? another cpython internal nobody asked for ? 15 years of Python and never used that not even sure i'll bother digging the doc to know about it.

next() // the 3.4 one ( already in but stayed turned off for whatever reason).

The reason was explained to you less then a month ago in an issue you created specifically for it :)

ANY kind of user finalizers ( personnally i'm in favour of JS group finalizers kind ).

Not sure what you mean exactly, but if anything gets implemented, for such a core feature we cannot really deviate from the standard imo and there's only one type of finalizer?

See #525 for related discussion about implementation of MRO.