Very little has changed. In Python 3.4 they removed the opcode
STORE_LOCALS, but in Micro Python we only ever used this for CPython
compatibility, so it was a trivial thing to remove. It also allowed to
clean up some dead code (eg the 0xdeadbeef in class construction), and
now class builders use 1 less stack word.
Python 3.4.0 introduced the LOAD_CLASSDEREF opcode, which I have not
yet understood. Still, all tests (apart from bytecode test) still pass.
Bytecode tests needs some more attention, but they are not that
important anymore.
I upgraded to Python 3.4.0, so needed to make these changes. Hopefully
the tests still run with Python 3.3.x (the scripts use python3 so are
agnostic as to the subversion).
Bytecode tests are tightly coupled to the Python version, and now some
fail against Python 3.4.
This adds support for almost everything (the comma isn't currently
supported).
The "unspecified" type with floats also doesn't behave exactly like
python.
Tested under unix with float and double
Spot tested on stmhal
It's not completely satisfactory, because a failed call to __getattr__
should not raise an exception.
__setattr__ could be implemented, but it would slow down all stores to a
user created object. Need to implement some caching system.
Because it's runtime reflection feature, not required for many apps.
Rant time:
Python could really use better str() vs repr() distinction, for example,
repr(type) could be "<class 'foo'>" (as it is now), and str(type) just
"foo". But alas, getting straight name requires adhoc attribute.
Don't store final, failing value to the loop variable. This fix also
makes for .. range a bit more efficient, as it uses less store/load
pairs for the loop variable.
There was thinkos that either send_value or throw_value is specified, but
there were cases with both. Note that send_value is pushed onto generator's
stack - but that's probably only good, because if we throw exception into
gen, it should not ever use send_value, and that will be just extra "assert".
In this case, the exception is just re-thrown - the ideas is that object
doesn't handle this exception specially, so it will propagated per Python
semantics.
Paul Sokolovsky
Damien George
Dave Hylands