RFC: detecting capabilities at runtime

[lurch]

I haven't been following the micropython project very closely, so apologies if this has been discussed before, or if this is the wrong place to ask about this...

With the launch of https://github.com/micropython/micropython-lib (which AFAICT was proposed in #405) I guess it's conceivable that there might be different code-paths in "standard library code", based on what different features (e.g. float support) are or aren't compiled into the particular micropython binary that's currently running?

Would it make sense to have some kind of runtime-API that could be queried, to allow modules from micropython-lib to dynamically adapt based on what features are available in any particular micropython binary?

Or is that a silly question because it would just end up bloating stuff too much?
</noob> ;-)

[dpgeorge]

The micropython-lib is mostly (soley) for the unix port, to (hopefully!) get some existing real world Python programs to run under uPy.

It is not intended for the version of uPy running on pyboard to access or use these libraries (although it could in principle).

[lurch]

Ah, fair enough. So everything in micropython-lib should just assume that it's running under the unix port of micropython, and assume it's always been compiled with all features enabled?

Feel free to close this issue as invalid.

[pfalcon]

based on what different features (e.g. float support) are or aren't compiled into the particular micropython binary that's currently running?

There might be. But are there? It will spread us to thin to foresee everything which might be needed, vs something which has value for realistic goals set forth so far. That said, your specific case (float support) should be very easy to cover by checking of "float" symbol availability in global namespace. Bingo.

Would it make sense to have some kind of runtime-API that could be queried

So, IMHO, not before there's realistic usecase for that. But it's easy to foresee need to generically differentiate CPython from MicroPython. I had that idea, but no specific means to implement. Checking for "micropython" module availability doesn't seem robust (we already have basic stub of it for CPython in examples/). Perhaps add something to sys? Ideas welcome.

[pfalcon]

The micropython-lib is mostly (soley) for the unix port, to (hopefully!) get some existing real world Python programs to run under uPy.

Something like that, at least for the realistic mid-term. So, I'd discourage anyone to apply fine hacking to micropython-lib: ideally, it should be all (re)written from scratch, but there's no resources for that. Here's realistic roadmap:

1. If you want to do fine and clean hacking, hack on micropython core - there're lot to do.
2. If you want to do quick&dirty hacking to slide towards being able to run existing real-world python code, hack on micropython-lib, but it should be quick&dirty indeed (take module from CPython, comment out or delete stuff we "don't need" to support, then again, hack on micropython core to get rest of the code run).

Surely, that's just proposed roadmap - not every module should be done like that, and not every developer should do it like that.

[lurch]

Perhaps add something to sys? Ideas welcome.

Sounds good to me ;-) #446

Or maybe https://docs.python.org/3.3/library/platform.html would be a better place for that kind of info?

[skgsergio]

What about:

platform.python_implementation()
    Returns a string identifying the Python implementation. Possible return values are: ‘CPython’, ‘IronPython’, ‘Jython’, ‘PyPy’.

[dpgeorge]

platform.python_implementation() seems the most sensible way to distinguish uPy. But how many scripts actually use this?

[dhylands]

I'd also like to see something which reflects the float implementation and int implementation, and also how big a small-int is.

Then we can write tests that test things that will test based on the implementation actually being used.

This becomes especially significant when we start doing tests on device.

[dpgeorge]

I'd also like to see something which reflects the float implementation and int implementation, and also how big a small-int is.

I don't think there's a standard way in Python to do this, since ints should be transparent and arbitrary in precision.

Easiest thing would therefore be to add some constants to the micropython module, akin to C's INT_MAX etc.

[Anton-2]

Isn't this what sys.int_info and sys.float_info are for ?

[dpgeorge]

Right you are, @Anton-2. float_info would be useful, but int_info doesn't have the correct fields: we would also need something like int_info.small_int_bits.

[dhylands]

I think that sys.maxint (which was removed in python 3) could be used for the LONGLONG and NONE implementations and not be present for MPZ (since that's what python 3 is now using).

sys.float_info looks like it would could be filled out and be usable by tests.

[Anton-2]

We should fill sys.maxsize too, it's generally used to distinguish between 32 and 64 bits builds.

[pfalcon]

platform.python_implementation() seems the most sensible way to distinguish uPy. But how many scripts actually use this?

I'd put it differently: "platform" seems to be nice, full-fledged, and bloated way to handle that. I imagine it as a python module, which uses something more simple and low-level to differentiate implementation. Having something in sys (e.g. sys.micropy_versions) apparently the best idea after all.

[pfalcon]

sys.implementation https://docs.python.org/3.3/library/sys.html#sys.implementation appears to be less (unfortunately, just slightly less) bloated way to specify implementation name, version, etc.

[dpgeorge]

Yes, sys.implementation looks like a better option than providing the platform module. We already have sys in the core, so not such a big addition.

[pfalcon]

I hope the outcome of discussion is clear: we should use standard Python (CPython) features for detection whenever possible, but each of them should be implemented on real demand (per-feature tickets with argumentation are welcome). Few were implemented already.

[pfalcon]

sys.maxsize was finally implemented in 4e0eeeb