RFC: Configurability and parametrization about micropython HOT 49 CLOSED

Flash memory is not that scarce that you would want to disable individual functions. Sets of functions makes more sense I think. Eg advanced string functions vs basic string functions.

I like the idea of having a default mpconfig.h, and only overriding the options in the port's mpconfig.h.

It would be good to put the USE_READLINE config in a .h file, somehow. I prefer that to using gcc command line -D options.

from micropython.

Flash memory is not that scarce

On F405? What about other micros? Current stm binary size is ~115K, which means it still fits into 128K (and hopefully leaves some room fast). But binary size grows fast.

Also, for me the threshold is the size of Lua. I mentioned that I previously hacked on Squirrel and it was noticeably bigger than Lua, but that's because Squirrel has native class support, etc., while Lua lacks that all. Still, with trivial size matching (required part of PRing a language) Lua won. When I heard you saying that you have pretty complete Python VM in ~60K I thought "pure magic"! Well I didn't try to build just VM so far, but current unix "py" (without me looking into optimizing it) is already bigger than what I was able to achieve with Squirrel (after some optimization).

Bottom line: as you add features, binary size grows, and grows fast. Each new method of builtin type, each exception message eats up bunch of bytes. And the only way to achieve/keep some size target is to make it well configurable (that will also let it stand out of competition, because I so far didn't see advanced well-parametrizable interpreters).

Eg advanced string functions vs basic string functions.

Well, AFAIK Python doesn't classify its functions/methods into "basic" and "advanced", so that all would be subjective. Whereas selecting methods one by one is pretty formal and allows to apply automated optimization methods, like extension to @Neon22's python-flavin - analyze and prune not only bytecode from the app, but from interpreter build to run it.

I don't say it should be immediate aim, or that everyone when adding methods should follow it, I just want to know if you're against such level of detail, or basically OK. If you have any concerns, like proliferation of #ifdef's, let me know. There would be more "structural" ways to handle that, but it will require more magic from compiler/linker to actually achieve the result.

All in all, #59 is research case how to do such things (including ideas on how to support optimized semantic subset vs generic CPython semantics).

from micropython.

Well, AFAIK Python doesn't classify its functions/methods into "basic" and
"advanced", so that all would be subjective. Whereas selecting methods one
by one is pretty formal and allows to apply automated optimization methods,
like extension to @Neon22 https://github.com/Neon22's python-flavin -
analyze and prune not only bytecode from the app, but from interpreter
build to run it.

Maybe it could be done in a similar way to how Linux kernel modules are
compiled: to use a ./configure script (that could also be done to manage
the platfom-specific flags) that by default generate a full-fledged binary,
but where you could be able to disable independent methods from the classes
(or directly the classes) and if later it's being called dispatch a
KeyError or similar (don't remember what's the exact Python error when
calling to methods that don't exists), and also this ./configure would be
generated doing on the desktop a static analysis of the code so you could
get an optimized binary for your script. It could seems strange to need to
compile "something" to use Python, but the ones that will need this kind of
optimization will be the ones that truly know what they are doing, for the
casual homebrew programmer with the standar full-fledged compilation it
will be enough...

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

from micropython.

@piranna, good thought on using Linux kconfig-like interface for that. I'm sure if we'd allow such detailed level of configurability, someone will add kconfig frontend for it, people would love it ;-).

the ones that will need this kind of optimization will be the ones that truly know what they are doing

Yup. Note that I'm personally not going to make each and every methods configurable - that's damn lot of work, which one would rather do on one's job or contract. But I'd love uPy to provide framework to allow that, then over time and on demand, it can grow per users' needs.

from micropython.

@pfalcon: for the record, "60k" is the stm binary size without peripherals. A lot of the 120k is fatfs support (around 10k), cc3000 wifi support (yes, that's turned on at the moment), and a bunch of stm peripherals. x86/x64 compiled code is more than 2 times the thumb equivalent. Sorry to disappoint/mislead you on this. The project is aimed mainly at micros, so the thumb size is the one I'm interested in.

That said, I'm all for supporting the development of the unix port, and keeping it lean. I'm all for having a lot of configuration options to allow tuning of the binary size, trading off features, etc.

One way of working out what Python features are most used is to run some kind of profiling version of CPython/uPy on a huge set of real-world Python scripts. Eg, add features to uPy until 90% of the scripts run correctly.

from micropython.

I like the idea of having a minimal/skeletal Python interpreter that has almost zero builtin methods/types. Of course, it's not right to call it "Python" then. But that would be a good base to start from, to which you could add builtins/types/modules as you needed them, to suit your application. The zero-base will just throw a lot of NotImplemented or AttributeError or NameError exceptions when you tried to use unimplemented stuff. But the basic structure (syntax and semantics) would be there, like generators, closures, exceptions, classes. A Python skeleton if you will.

Probably the best way to get at this is to first add stuff, then selectively take things away. You would want to have it so that at each stage of reduction, you were always a strict subset of CPython.

from micropython.

@piranna https://github.com/piranna, good thought on using Linux
kconfig-like interface for that. I'm sure if we'd allow such detailed level
of configurability, someone will add kconfig frontend for it, people would
love it ;-).

I'm happy you liked :-)

the ones that will need this kind of optimization will be the ones that
truly know what they are doing

Yup. Note that I'm personally not going to make each and every methods
configurable - that's damn lot of work, which one would rather do on one's
job or contract. But I'd love uPy to provide framework to allow that,
then over time and on demand, it can grow per users' needs.

Yeah, that is the idea, offer a group of macros that allow to include new
functionality selectively using a kconfig, something like

MPYTHON_REGISTER_CLASS("list", klass_list)
MPYTHON_REGISTER_METHOD("list", "add", klass_list_add)

and later on the kconfig you could disable the list.add method or also
the full list class.

[x] list
[x] `>add

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

from micropython.

Probably the best way to get at this is to first add stuff, then
selectively take things away. You would want to have it so that at each
stage of reduction, you were always a strict subset of CPython.

Maybe it would be easier first to remove all the modules and the built-ins
and left only the parser without runtime raising errors for everything
(maybe then the minimal runtime would need to have the Exceptions
hierarchy, isn't it?), later add the built-ins using the kconfig macros to
register them, and keep going on with the modules.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

from micropython.

The runtime would need to be able to raise errors, that's basic functionality. Typing x in a fresh REPL must raise a NameError.

We should perhaps separate out the tests that test core stuff, from those that test builtins, etc.

We could use the tests to define what the skeletal Micro Python is (ie what subset of Python it implements).

from micropython.

Seems good to me. Maybe also the REPL would moved out of the core runtime?
It needs a terminal comunication, and sys.stdin and sys.stdout, and I think
they would also be moved out...

Send from my Samsung Galaxy Note II
El 04/01/2014 16:12, "Damien George" [email protected] escribió:

The runtime would need to be able to raise errors, that's basic
functionality. Typing x in a fresh REPL must raise a NameError.

We should perhaps separate out the tests that test core stuff, from those
that test builtins, etc.

We could use the tests to define what the skeletal Micro Python is (ie
what subset of Python it implements).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/35#issuecomment-31580295
.

from micropython.

I have been looking about and seems kconfig parser is available as an independent project called "kconfig-frontends" and there are also some distro packages, so maybe we could start looking about adapting MicroPython configuration to it:

http://ymorin.is-a-geek.org/projects/kconfig-frontends

from micropython.

I'm all for having a lot of configuration options to allow tuning of the binary size, trading off features, etc.

Thanks! I hope you won't regret saying this, as well, common wisdom says that more configurability means more maintenance work. But I don't think it has that much overhead if done right. After all, once core is done, it's mostly static and optimizing it for various runtime scenarios is what you'd do to it.

One way of working out what Python features are most used is to run some kind of profiling version of CPython/uPy on a huge set of real-world Python scripts.

Well, since day1 I'd like to run some existing codebase and see how it goes. But I don't think anything real-world would run yet (my initial target is to write http server (be it http.server or not)), intermediate target is no-nonsense text-processing script. I submitted #90 as way towards having some real-world code at the fingertips ;-).

from micropython.

Slight side-tangent to this discussion...

I've just noticed that in stmhal/mpconfigport.h we have defines like:
#define MICROPY_ENABLE_GC (1)
and
#define MICROPY_ENABLE_LFN (1)

MICROPY_ENABLE_GC is "declared/described" in py/mpconfig.h and the value here 'overrides' it, whereas MICROPY_ENABLE_LFN is directly "declared/described" inside stmhal/mpconfigport.h (i.e. it's specific to only that port).
I wonder if it'd be worth adding some kind of standard-prefix (something like MICROPYPORT_ENABLE_LFN), to more clearly differentiate those config-options which are 'global', and those which are 'port-specific' ?

from micropython.

See mpconfigboard.h, in, eg boards/PYBV10/. It uses _HW_.

from micropython.

So, we already have a generic board-specific #define prefix, could we also have a generic port-specific #define prefix?
Or would it just overcomplicate things?

from micropython.

Dunno, it seems to be more useful to have naming basic on semantic categories (e.g. specific prefix for hardware-related stuff), than based on where it's defined.

But it would be nice to revisit naming, for example, have consistent naming scheme for enabling/disabling modules, types, specific methods of types, etc.

from micropython.

I just figured that if you wanted to change the flag, or investigate in more detail what it does/where it's used, if the flag had a port-specific prefix you'd know to look in the port directory (e.g. stmhal/) rather than in the global directory (i.e. py/)

...and on a (slightly) related note, how come some things like MICROPY_MOD_SYS_STDFILES are in unix/mpconfigport.h whereas other things like MICROPY_MOD_TIME are in unix/mpconfigport.mk ?

from micropython.

if the flag had a port-specific prefix you'd know to look in the port directory

Well, maybe that's usecase. General concern is that make option names longer and longer. (For consistency, prefix then should be MICROPY_PORT_).

...and on a (slightly) related note, how come some things like MICROPY_MOD_SYS_STDFILES are in unix/mpconfigport.h whereas other things like MICROPY_MOD_TIME are in unix/mpconfigport.mk ?

Some modules require external libs, and those cannot be controlled from .h file. So, need to control it from Makefile. Then, it was proposed that enabling port-specific modules are controlled from .mk. Maybe that's not ideal, but do you have better ideas?

from micropython.

Some modules require external libs, and those cannot be controlled from
.h file. So, need to control it from Makefile. Then, it was proposed that
enabling port-specific modules are controlled from .mk. Maybe that's not
ideal, but do you have better ideas?

I proposed some time ago about using kconfig, but looking how complicated
is getting the configuration, maybe it would be good to start defining it
from scratch: minimal core + extra functionality, kconfig, common code +
per platform... Too much work that should be done synchronized, so better
do it in a dedicated branch, isn't it?

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

from micropython.

do it in a dedicated branch, isn't it?

Or just later - there's not enough config options now to justify spending effort on it. YMMV.

from micropython.

IMHO it's one of those double-edged swords. Do it too early, and there's "not enough config options" to make it worthwhile (see the feedback I got on #495). But leave it too late and it's "too diffiicult to adapt all the existing options" to make it worthwhile.

from micropython.

@piranna: your opinion welcome on http://forum.micropython.org/viewtopic.php?f=3&t=48#p182 and following msgs

from micropython.

Ok, time has come to provide consistent naming for options which configure availability of specific methods. Proposal: should provide complete path: module - type - method. As that's going to be long, could drop noise words like "ENABLE". For builtin functions, module is "BUILTINS". Type/class is optional. For special methods, naming is as expected. Examples:

MICROPY_SYS_EXIT
MICROPY_BUILTINS_STR___MODULO__

from micropython.

deaeaac went with this last proposal in mind (which otherwise surely needs to be reviewed and elaborated).

from micropython.

MICROPY_... sounds reasonable:

• MICROPY_ALLOC_... for allocation policy
• MICROPY_EMIT_... to control emitters

But how to differentiate "enable GC" and "include GC module"?

from micropython.

My proposal few comments above goes more along the line of:

• If feature enables something in Python scope, it's MICROPY_(pymodule)(pytype)(pymethod)
• Other features keep their naming.

That would lead to MICROPY_GC (enable module "gc") and MICROPY_ENABLE_GC (enable GC support), which is different, but not much clear.

I kinda on purpose left it like that, to call for bright ideas from other folks. Without further commentary, I can also mass-propose:

MICROPY_MOD_STRUCT
MICROPY_TYPE_STRUCT_STRUCT
MICROPY_METH_STRUCT_PACK

MICROPY_STRUCT_MOD
MICROPY_STRUCT_STRUCT_TYPE
MICROPY_STRUCT_PACK_METH

MICROPY_PY_STRUCT
MICROPY_PY_STRUCT_STRUCT
MICROPY_PY_STRUCT_PACK

from micropython.

With your previous proposal (MICROPY_<module>_...) I'm just affraid of the future cases where clashes with other things like DEBUG, ALLOC, EMIT, etc. Having it MICROPY_MOD__... prevents such clashes. Eg for GC, MICROPY_MOD_GC makes it pretty clear what you are enabling.

from micropython.

Yes, but how do we deal with types within modules, then their methods (and module-level functions (which I still call module methods to not explode configuration terminology))?

from micropython.

They would still be as you propose. The MICROPY_MOD_<module>_ prefix opens up the namespace/scope for that module, and it's then free to do what it wants within that scope. WIthin a module you won't have a module-level function the same name as a class (or type or constant), so they can co-exist with that prefix.

from micropython.

As I made many different proposals, can you please write down finalized conventions, with examples? ;-)

from micropython.

Well, it's not that bad as it is right now. Except that I accidentally used MP_ALLOC_ for allocation policy, rather than MICROPY_ALLOC_. Remind me, why did we go for MICROPY_ in config, and MP_ for macros and defines? I guess this is okay, since it separates config from internal code.

How about just keeping things as they are, except change MICROPY_ENABLE_MOD_X to MICROPY_MOD_X?

from micropython.

I guess this is okay, since it separates config from internal code.

IIRC, that was exactly the reason. Not too late to change, fairly speaking.

How about just keeping things as they are, except change MICROPY_ENABLE_MOD_X to MICROPY_MOD_X?

We cannot "keep things as they are" in literal sense, because we don't have any (organized) support for adding enabled/disable options for individual types, methods, functions, and want to have such support. So naming scheme for those cases should be explicitly defined ;-).

from micropython.

Here is a collection of all configuration variables to date, organised into category:

compiler features and config
    MICROPY_EMIT_CPYTHON
    MICROPY_EMIT_X64
    MICROPY_EMIT_THUMB
    MICROPY_EMIT_INLINE_THUMB
    MICROPY_ENABLE_CONST
memory policy and gc
    MP_ALLOC_LEXER_INDENT_INIT
    MP_ALLOC_LEXEL_INDENT_INC
    MP_ALLOC_PARSE_RULE_INIT
    MP_ALLOC_PARSE_RULE_INC
    MP_ALLOC_PARSE_RESULT_INIT
    MP_ALLOC_PARSE_RESULT_INC
    MP_ALLOC_SCOPE_ID_INIT
    MP_ALLOC_SCOPE_ID_INC
    MICROPY_PATH_MAX
    MICROPY_ENABLE_GC
    MICROPY_ENABLE_GC_FINALISER
    MICROPY_MEM_STATS (also debug)
debug
    MICROPY_DEBUG_PRINTERS
helpers for ports
    MICROPY_ENABLE_REPL_HELPERS
    MICROPY_ENABLE_LEXER_UNIX
machine/port config
    MP_ENDIANNESS_LITTLE
    MICROPY_STREAMS_NON_BLOCK
pure optimisation
    MICROPY_USE_COMPUTED_GOTO
py core features non semantical
    MICROPY_ENABLE_SOURCE_LINE 
    MICROPY_ENABLE_DOC_STRING 
    MICROPY_ERROR_REPORTING
py core features
    MICROPY_LONGINT_IMPL
    MICROPY_FLOAT_IMPL
    MICROPY_ENABLE_FLOAT
    MICROPY_CPYTHON_COMPAT
    MICROPY_ENABLE_SLICE
    MICROPY_ENABLE_FROZENSET
    MICROPY_ENABLE_PROPERTY
modules (include or not)
    MICROPY_ENABLE_MOD_COLLECTIONS
    MICROPY_ENABLE_MOD_MATH
    MICROPY_ENABLE_MOD_CMATH
    MICROPY_ENABLE_MOD_GC
    MICROPY_ENABLE_MOD_IO
    MICROPY_ENABLE_MOD_STRUCT
    MICROPY_ENABLE_MOD_SYS
        functions within module
        MICROPY_MOD_SYS_EXIT
        MICROPY_MOD_SYS_STDFILES
extras for ports
    MICROPY_EXTRA_BUILTINS
    MICROPY_EXTRA_BUILTIN_MODULES
    MICROPY_EXTRA_CONSTANTS

Need to make sense of it.

from micropython.

Some work towards this in 58ebde4.

from micropython.

To support deep and complex configurability we undoubtedly need a complex naming scheme. But until we know the extent of such configurability, we can use a modest scheme.

How about the following.

For core Python language features, prefix with MICROPY_PYC_:

MICROPY_PYC_SLICE
MICROPY_PYC_FLOAT

For builtins, use MICROPY_PYB_:

MICROPY_PYB_PROPERTY
MICROPY_PYB_FROZENSET

For anything in the Python library, use MICROPY_PYL_:

MICROPY_PYL_SYS (enable sys module)
MICROPY_PYL_MATH
MICROPY_PYL_SYS_EXIT (enable sys.exit)
MICROPY_PYL_STRUCT_STRUCT (enable struct.Struct type)

Things in the Python library should not clash, by definition. Only issue would be capitilisation, eg struct.Struct vs struct.struct (which is not a problem because struct.struct does not exist).

from micropython.

To support deep and complex configurability we undoubtedly need a complex naming scheme.

I would disagree - to support complex configurability we should have simple, clean, and obvious naming scheme - it may lead to long and unwieldy identifiers, but well, that's just a mirror of complex configurability.

PYB, PYC, PYL are IMHO confusing abbreviations (syntax), and potentially confusing semantics:

MICROPY_PYC_SLICE
MICROPY_PYC_FLOAT

• one may argue these are not "core features", but just a builtin names.

For builtins, use MICROPY_PYB_:
For anything in the Python library, use MICROPY_PYL_:

How builtins (just a special pre-imported module) are different from "Python library", and how "sys" is "python library" (it's builtin module).

But forgetting about different PYB/PYC/PYL prefixes (and what they mean), that's pretty close to (one of) examples I gave above.

from micropython.

MICROPY_PYC_SLICE
MICROPY_PYB_FLOAT
MICROPY_PYL_SOMETHING

That's 2 PY's after each other :) with no added information. Also PYB is quite confusing imo since to me it reads PYBOARD, not PYBUILTIN.
Wouldn't it be more clear to just use proper names like

MICROPY_CORE_SLICE
MICROPY_BUILTIN_FLOAT
MICROPY_LIB_SOMETHING

It's not even that much longer, but much more readable I do think there is a distinction between CORE and BUILTIN but maybe not exactly like the one you propose. For example the GC could be a CORE part.

from micropython.

it may lead to long and unwieldy identifiers,

I was under the impression that you were pushing for short identifiers (eg MICROPY_IO_BYTESIO instead of MICROPY_MOD_IO_BYTESIO). I have no problem with long identifiers.

For float, there is the core implementation of float type (eg being able to type 1.2), and separately is the builtin called float. Hence the need to distinguish core from builtin. Arguably they could be the same in the case of float, but not all core features (eg multiple inheritance) have cleanly associated builtins.

Wouldn't it be more clear to just use proper names like

MICROPY_CORE_SLICE
MICROPY_BUILTIN_FLOAT
MICROPY_LIB_SOMETHING

Yes, that would make it more obvious what the names refer to.

There are (at least) 2 types of core: core stuff like GC, VM, compiler features/config, and core Python language features like slice, float, doc strings. That's why I wanted to put PY in there again, to make it clear that this option configures the compatibility with (C)Python.

So it could be MICROPY_PY_CORE_SLICE and MICROPY_CORE_GC, for example.

from micropython.

I was under the impression that you were pushing for short identifiers (eg MICROPY_IO_BYTESIO instead of MICROPY_MOD_IO_BYTESIO). I have no problem with long identifiers.

More specifically, for not including extra prefixes (infixes?) when they're just extra chore to have (for example, when they add more confusion than disambiguation, or when no disambiguation is actually needed).

Arguably they could be the same in the case of float, but not all core features (eg multiple inheritance) have cleanly associated builtins.

That's why I brought up a specific proposal: let's define naming scheme for configuration of Python-level API [leaving the rest mostly as is]. I see that you're going for more general naming refactor, but I personally dunno if we have good basis to do that now (any proposal could get counter-arguments a-la "what if it's actually different structure/hierarchy").

On the other hand, Python API hier is well-defined and unambiguous - everything lives in a module (that's module "builtins" if it's available in global namespace), and have path down from there.

What if we start with defining naming scheme for that after all, and then proceed to things like CORE_SLICE, CORE_GC, etc. if you think it's clear that's the right approach for these other things?

So, how about shortening "Python API" to "PY", and using that as an infix:

MICROPY_PY_STRUCT
MICROPY_PY_STRUCT_STRUCT
MICROPY_PY_STRUCT_STRUCT_PACK
MICROPY_PY_STRUCT_PACK

show respectively option for enabling module, class, method of a class, and module-level function.

from micropython.

Okay, reiterating what is said above: MICROPY_PY_ is the prefix to use for a configuration that enables a (C)Python named-entity, where the name of that named-entity is the suffix of the variable name.

Such names won't clash with any other configuration variables because other variables start with MICROPY_X_, where X is not PY. Deciding to use MICROPY_PY_ now does not interfere with how we decide to structure the rest of the variables later (but is consistent with existing MICROPY_ALLOC_, MICROPY_EMIT_ etc).
Builtins can start with MICROPY_PY_BUILTIN_.

Only problem then is with case conversion (ie clash with struct vs Struct). At the risk of making names long, could prefix names with their "type", eg: MICROPY_PY_MOD_STRUCT_CLASS_STRUCT_METH_PACK. To be completely verbose, it would be MICROPY_ENABLE_PYTHON_FEATURE_MOD_STRUCT_CLASS_STRUCT_METH_PACK.

from micropython.

Hello,

On Fri, 23 May 2014 04:17:43 -0700
Damien George [email protected] wrote:

Okay, reiterating what is said above: MICROPY_PY_ is the prefix to
use for a configuration that enables a (C)Python named-entity, where
the name of that named-entity is the suffix of the variable name.

Such names won't clash with any other configuration variables because
other variables start with MICROPY_X_, where X is not PY.
Deciding to use MICROPY_PY_ now does not interfere with how we
decide to structure the rest of the variables later (but is
consistent with existing MICROPY_ALLOC_, MICROPY_EMIT_ etc).
Builtins can start with MICROPY_PY_BUILTIN_.

Yes, correct.

Only problem then is with case conversion (ie clash with struct vs
Struct).

I don't think this is going to be common, and can be disambiguated when
actually happens with just a suffix (e.g. _CLASS or _FUNC).

At the risk of making names long, could prefix names with
their "type", eg: MICROPY_PY_MOD_STRUCT_CLASS_STRUCT_METH_PACK.
To be completely verbose, it would be
MICROPY_ENABLE_PYTHON_FEATURE_MOD_STRUCT_CLASS_STRUCT_METH_PACK.

---

Reply to this email directly or view it on GitHub:
#35 (comment)

Best regards,
Paul mailto:[email protected]

from micropython.

Okay, all those variables controlling Python features have been renamed to MICROPY_PY_*. The builtins like property and slice are simply MICROPY_PY_PROPERTY, etc. Could prefix them with _BUILTIN_, but that's not really necessary, since these names are always different from module names, and should never clash with anything.

Remains to decide about things like MICROPY_ENABLE_FLOAT, which controls globally the use of floating point numbers.

from micropython.

Remains to decide about things like MICROPY_ENABLE_FLOAT, which controls globally the use of floating point numbers.

I find floats a special case: some would enable it, others disable it,
and others enable it by an external library due to lack of native
support on the target platform. Is "enable" the correct word for this?

from micropython.

At the moment, "enable" is the correct word because there is no configurability except on/off. For using external libraries, or soft floating point functions, it's still the same in the uPy core: you use standard C floating point support (float or double).

from micropython.

Thanks for this refactor!

The builtins like property and slice are simply MICROPY_PY_PROPERTY, etc. Could prefix them with BUILTIN, but that's not really necessary, since these names are always different from module names, and should never clash with anything.

Yeah, but that's inconsistent exception from common scheme ;-).

Remains to decide about things like MICROPY_ENABLE_FLOAT, which controls globally the use of floating point numbers.

I just pushed refactor for slice implementation which makes it compliant with CPython - arbitrary objects are allowed as params (need that to properly implement slice assignment). Then the last step is just expose slice type via identifier. Granted, it's plausible to have a need for literal slices, and not proper type exposed, but not much feasible to craft config solution for such cases right away. Summing up: MICROPY_PY_BUILTINS_SLICE can control all aspects of slice.

Now try to apply the same login to floats: whenever someone wants to support true division, they likely will want to have "float" identifier. Thus, MICROPY_PY_BUILTINS_FLOAT could control all aspects of float. A bit unexpected, yeah, it's comfortable to think of float as of "special feature". No problem, I just think about pruning unneeded stuff from config space. No need to rush into it, just give it a thought ;-).

from micropython.

Yeah, but that's inconsistent exception from common scheme ;-).

How so? The prefix MICROPY_PY_ is for use when configuring "names" of Python objects. If we define "names" to always start with their module, then yes, it's inconsistent. But, if we define "names" to mean those accessible from the global contect (like float, slice, etc), then it's consistent.

from micropython.

Okay, I went with @pfalcon 's suggestion to put builtins (including float) in MICROPY_PY_BUILTINS_* namespace.

Still have somewhat inconsistent MICROPY_FLOAT_IMPL and friends. I will change it to MICROPY_PY_BUILTINS_FLOAT_IMPL for consistency if there are no objections on length of these variables :)

from micropython.

@dpgeorge : Sorry for not replying earlier, but yes, my original idea was to always have a namespace specifier, to avoid possible confusion and ambiguity.

And yes, if you generally approve of the idea that anything float related also relates to Python's float type, then MICROPY_PY_BUILTINS_FLOAT_IMPL sounds reasonable. Again, I'm not sure about this last matter completely, but imho, overall scheme clicks nice together, so better to have generic scheme to follow all the time, than scratch head how to deal with each case.

from micropython.

This can be closed because configuration has been well defined for some time. A short summary:

• py/mpconfig.h provides the master list of configuration options (the ones controlling all code in py/ and most of the code in extmod/). It provides sensible defaults for when config options are not specified by mpconfigport.h. When creating an mpconfigport.h file it's recommended to only define those config options which are different from the default.
• Options that control entities in the Python API are named MICROPY_PY_xxx. There are some special cases like MICROPY_PY_ASYNC_AWAIT, but for the most case they are of the form MICROPY_PY_<module> to enable a module, MICROPY_PY_<module>_<class> to enable a specific class/feature within a module, and MICROPY_PY_BUILTINS_<name> to enable a specific builtin/feature.
• Most other options start with MICROPY_ are should be descriptive enough.

from micropython.