| Age | Commit message (Collapse) | Author |
|
Includes support for native bases.
|
|
|
|
|
|
|
|
MicrpPython test should print single "SKIP" line for test to be skipped.
|
|
"object" type in MicroPython currently doesn't implement any methods, and
hopefully, we'll try to stay like that for as long as possible. Even if we
have to add something eventually, look up from there might be handled in
adhoc manner, as last resort (that's not compliant with Python3 MRO, but
we're already non-compliant). Hence: 1) no need to spend type trying to
lookup anything in object; 2) no need to allocate subobject when explicitly
inheriting from object; 3) and having multiple bases inheriting from object
is not a case of incompatible multiple inheritance.
|
|
Addresses issue #592.
|
|
|
|
Should support everything supported by strings.
|
|
You can now do:
X = const(123)
Y = const(456 + X)
and the compiler will replace X and Y with their values.
See discussion in issue #266 and issue #573.
|
|
|
|
Inspired by discussion in #577. So, in this case of builtin function,
passing args by keyword has less than 1% overhead.
|
|
Passing 3 args with keywords is for example 50% slower than via positional
args.
|
|
|
|
... and we have not that bad mapping type after all - lookup time is ~ the
same as in one-attr instance. My namedtuple implementation on the other
hand degrades awfully.
So, need to rework it. First observation is that named tuple fields are
accessed as attributes, so all names are interned at the program start.
Then, really should store field array as qstr[], and do quick 32/64 bit
scan thru it.
|
|
That's higher than instance field access - behold the power of hashing.
|
|
|
|
|
|
Need to have a policy as to how far we go adding keyword support to
built ins. It's nice to have, and gets better CPython compatibility,
but hurts the micro nature of uPy.
Addresses issue #577.
|
|
Also compared with method abstraction for accessing instance vars -
it's more than 3 times slower than accessing var directly.
|
|
Motivation is optimizing handling of various constructs as well as
understanding which constructs are more efficient in MicroPython.
More info: http://forum.micropython.org/viewtopic.php?f=3&t=77
Results are wildly unexpected. For example, "optimization" of range
iteration into while loop makes it twice as slow. Generally, the more
bytecodes, the slower the code.
|
|
|
|
|
|
In tests/pyb is now a suite of tests that tests the pyb module on the
pyboard. They include expected output files because we can't run
CPython on the pyboard to compare against.
run-tests script has now been updated to allow pyboard tests to be run.
Just pass the option --pyboard. This runs all basic, float and pyb
tests. Note that float/math-fun.py currently fails because not all math
functions are implemented in stmhal/.
|
|
|
|
This is ugly, just as expected.
|
|
Fixes #539
|
|
|
|
|
|
Even of these, some features do not yet work as expected.
|
|
Had choice of either interning or forcing full equality comparison, and
chose latter. See comments in mp_map_lookup.
Addresses issue #523.
|
|
Implements 'def f(*, a)' and 'def f(*a, b)', but not default
keyword-only args, eg 'def f(*, a=1)'.
Partially addresses issue #524.
|
|
|
|
Share code with .strip(). TODO: optimize .rstrip().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I.e. with its own globals. So, just as for functions, we need to switch
globals when resuming a generator.
|
|
Allow the uPy used by run-tests to be overridden
|
|
Tests in basics (which should probably be renamed to core) should not
rely on float, or import any non-built-in files. This way these tests
can be run when those features are not available.
All test in basics now pass on the pyboard using stmhal port, except for
string-repr which has some issues with character hex printing.
|
|
As discussed in #504
|
|
Fixing the USB problem on stmhal now gets these 2 tests working.
|
|
|
|
with MICROPY_MP_PY envvar, in an analogous way to MICROPY_CPYTHON3 envvar.
(the reason for this will be made clearer by a later PR)
|
|
|
|
See the `skip_travis_tests` variable. Fixes #495
(also tidied up usage of os.path.basename() function)
|
|
|