Why do you want to make this module extensible? In general, this feature is only used to support CPython modules that we don't fully support in C, so they can be extended in Python.

For the openamp module we define it ourselves, so there's nothing missing that needs adding.

I extend in Python to add utils and classes that can be accessed with openamp.x. For example I have an EndpointIO class which is a subclass of IOBase that you can use for dupterm. Note that there's an openamp.Endpoint in the C-module, so openamp.EndpointIO belongs there too but as an extension.

Hm I guess my EndpointIO class would not be needed if #14181 is merged but I still have other extensions.

Note that there's an openamp.Endpoint in the C-module, so openamp.EndpointIO belongs there too but as an extension.

I don't think it's a good idea to add things to this module outside this repo. We should fully define the openamp module here, and have the docs here. Any extensions that work with openamp but are outside this repo (which would be third-party extensions, relative to this repo) should be placed in a separate module, eg openamp_ext, with separate docs. Otherwise it will get confusing what functions/classes are available in this module.

Eventually we want to get rid of this extensible module stuff (it's a backwards compatible way to support the old u-module naming scheme), so I don't want to add more modules that use this.

Eventually we want to get rid of this extensible module stuff (it's a backwards compatible way to support the old u-module naming scheme), so I don't want to add more modules that use this.

Whoa that will be a very breaking change. We heavily depend on extending modules for adding missing functionality or for portability. For example, we extend machine to add an LED that's used throughout or examples. We'll also extend it to mask missing machine.PWM for stm32 port. Can this feature be kept for such uses cases ?

If there's important additional C functionality then it should be added in this repo, with docs, so it's available on all ports. Or if that functionality is best implemented in Python, and it makes more sense to have it in openamp rather than a separate module, then it should go in micropython-lib and then, yes, the module would be extensible

I think this is all subjective. For example, I think we can all? agree that something like EndpointIO is useful to have, whether it's an extension or native (as implemented in #14181). However, the rest of the extensions, which BTW are Not yet ready for sharing, may or may not be welcome by the maintainers. However we'd still like to have them as an extension as they [in my opinion] logically belong to the same module, and as an extension we won't have to maintain or document a new module, and the users won't have to learn about a new module.

The point is, it's hard to agree on what's useful and what's not and what should be C or extension. The maintainers are of course free to decide on that, but I think they should not block others from extending the module if they want to, to best fit their needs.

I think this is all subjective

This is a tricky topic for sure, but I suggest the measurable aspect of what Damien is talking about is consistency. The extension mechanism is used to ensure consistency between MicroPython and CPython (i.e. extending os with os.path), or between different MP ports (i.e. extending machine.Pin to the unix port). In both cases there are docs for those modules already, and the extensions mechanism keeps the implementation (and therefore user experience) as consistent with those docs as possible.

However, the rest of the extensions, which BTW are Not yet ready for sharing, may or may not be welcome by the maintainers.

Either way, I think the preferred path for MicroPython and user experience would be to have a separate module here:

• If the additional Python-based functionality gets merged to micropython-lib, then this sounds like it fits well with the common pattern Damien already mentioned of bluetooth/aioble, machine.USBDevice/usb-device, etc.
• If the additional Python functionality is not merged to micropython-lib, then using the same module name would cause the MicroPython docs for the openamp module to be inconsistent with the docs for the external extended openamp module. Using a different name removes the ambiguity and improves the user experience.

If the additional Python functionality is not merged to micropython-lib, then using the same module name would cause the MicroPython docs for the openamp module to be inconsistent with the docs

But what if we don't want to push our extensions to micropython-lib even if they are in line with the upstream policy and will be merged ? Maybe we'd want to maintain them privately, or push them somewhere else, like arduino-lib and then we could also maintain our own docs for the module.
The reason for sending work like this upstream, in addition to contributing something useful, is to Not have fork and maintain it ourselves, but if we still have to fork and change the code that we ourselves put upstream just to be able to extend it, then what's the point of pushing it upstream in the first place.

Note that you can drop the extensible commit (it's in its own commit) if you don't want it, if this is ready to be merged.

then we could also maintain our own docs for the module.

It's of course your choice if you want to do that. I'd note that if there are two modules called openamp with different functions in them, and different docs for that module in two places, then this can easily lead to a bad user experience. i.e. Finding the docs for openamp (even openamp docs for the matching MP version) won't necessarily find the correct docs, because there will be two different implementations with the same name.

Sometimes that's unavoidable because of external constraints (and the history of MP has plenty of confusing incidents arising from those unavoidable name clashes). In this case it seems like it is avoidable, by giving different modules different names. Maybe I don't understand the use case here, though.

Note that you can drop the extensible commit (it's in its own commit) if you don't want it, if this is ready to be merged.

👍