MicroPython Forum (Archive)

In the course of using Micropython I've encountered a few unimplemented features. If these are on somebody's todo list there's no point in cluttering up github by filing these as bugs. I've not found a FAQ on this: do you want them reported at this stage in the project, and if so, how?

The kind of things I have in mind are things like this where micropython differs from cPython:
min() and max() won't accept the key argument
The following produces a syntax error:
"{0:{1}.{1}}".format("rats", 20)
Perhaps this last one is unfair as the docs do admit to restrictions in subclassing built in types:
If I subclass a list a call to the base class __setitem__() fails

Regards, Pete

I wrote most of the format code and I didn't realize you could even do recursive stuff

I was wondering how to specify a width as an argument using format (You would use %*.*s using modulo.

So I'll probably take a stab at fixing the format one.

That would be great: computed field widths are useful. Incidentally to get exactly the same left justified output you'd need %-*.*s using modulo.

I'm still not clear about my general point: should we report unimplemented features here or on github - or is it generally too early in the project's development to be reporting them at all?

Regards, Pete

Personally, if it's a feature you want, I'd be inclined to file an issue on github. Each issue should be very specific and only cover a single item.

Then there can be a discussion on the issue to decide how important it is. Some issues get fixed right away, others don't.

Worst case, you file the issue and it gets closed.

There is a wiki page here: https://github.com/micropython/micropyt ... ifferences which you should read. New issues that fit, can have a reference to the issue added. For example, there is a line item for "str.format() may miss few advanced/obscure features (but otherwise almost completely implemented)." So I'd add the issue number for not supporting the computed field widths with format.

Thanks for that, Dave. I've logged the two issues which strike me as most worth implementing given the intended application area.

I entirely accept the point about the standard libraries. Where I was unclear was whether the aim is to produce a complete implementation of a specific Python 3.x version or a subset. It now seems evident that the aim - in the interests of being "micro" - is to produce a subset. Presumably at some point in the project the subset will be documented and thereafter deficiencies relative to that specification should be logged.

Is this how you see the project progressing?

Regards, Pete

I think that the core language may very well become complete or very close to complete.

The standard libraries, I'm not as sure about. I expect that they'll come along as people need/want them and are willing to port them.

In MicroPython, its sometimes much more efficient to implement something in C rather than in python, so it becomes a balancing act.

I expect that MicroPython will remain a subset when looking at the standard libraries.