CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=6.1.x 2020-12-07T23:40:02+00:00 2020-12-07T23:40:02+00:00 Bernhard Boser boser@berkeley.edu 2020-12-07T23:16:16+00:00 urn:sha1:b5b6b6d0f2fe669e0304521d663b16388c63b15e 2020-10-11T06:39:32+00:00 Kenny 3454741+WarriorOfWire@users.noreply.github.com 2020-10-11T06:39:32+00:00 urn:sha1:98aa4b794346161e512d0fba913901021dd2cfbf 2020-09-12T19:07:23+00:00 Jeff Epler jepler@gmail.com 2020-09-12T18:57:31+00:00 urn:sha1:54d97251fe2dd4939652a186bf703885e654b4d1 While checking whether we can enable -Wimplicit-fallthrough, I encountered a diagnostic in mp_binary_set_val_array_from_int which led to discovering the following bug: ``` >>> struct.pack("xb", 3) b'\x03\x03' ``` That is, the next value (3) was used as the value of a padding byte, while standard Python always fills "x" bytes with zeros. I initially thought this had to do with the unintentional fallthrough, but it doesn't. Instead, this code would relate to an array.array with a typecode of padding ('x'), which is ALSO not desktop Python compliant: ``` >>> array.array('x', (1, 2, 3)) array('x', [1, 0, 0]) ``` Possibly this is dead code that used to be shared between struct-setting and array-setting, but it no longer is. I also discovered that the argument list length for struct.pack and struct.pack_into were not checked, and that the length of binary data passed to array.array was not checked to be a multiple of the element size. I have corrected all of these to conform more closely to standard Python and revised some tests where necessary. Some tests for micropython-specific behavior that does not conform to standard Python and is not present in CircuitPython was deleted outright. 2020-09-07T12:11:23+00:00 Jeff Epler jepler@gmail.com 2020-09-07T12:11:23+00:00 urn:sha1:7d58cdb12c001f5a4a0fdf2fc0d1e8c1d4029045 2020-09-06T14:53:16+00:00 Jeff Epler jepler@gmail.com 2020-04-28T14:13:49+00:00 urn:sha1:20c2dd0c0853f3f1f6a5fa23887f08ec5cf77818 This method of integer objects is needed for a port of python3's decimal.py module. MICROPY_CPYTHON_COMPAT is enabled by CIRCUITPY_FULL_BUILD. 2020-07-25T05:55:37+00:00 Jonathan Hogg me@jonathanhogg.com 2020-07-21T17:47:28+00:00 urn:sha1:901f3dce6e5e7c1501550ca0b7f3283848194a2e MicroPython's original implementation of __aiter__ was correct for an earlier (provisional) version of PEP492 (CPython 3.5), where __aiter__ was an async-def function. But that changed in the final version of PEP492 (in CPython 3.5.2) where the function was changed to a normal one. See https://www.python.org/dev/peps/pep-0492/#why-aiter-does-not-return-an-awaitable See also the note at the end of this subsection in the docs: https://docs.python.org/3.5/reference/datamodel.html#asynchronous-iterators And for completeness the BPO: https://bugs.python.org/issue27243 To be consistent with the Python spec as it stands today (and now that PEP492 is final) this commit changes MicroPython's behaviour to match CPython: __aiter__ should return an async-iterable object, but is not itself awaitable. The relevant tests are updated to match. See #6267. 2020-07-24T03:40:16+00:00 Kenny 3454741+WarriorOfWire@users.noreply.github.com 2020-07-22T01:31:18+00:00 urn:sha1:764d49e6416fe5b35b61a30981f326435a9a5c91 2020-07-24T03:40:16+00:00 Kenny 3454741+WarriorOfWire@users.noreply.github.com 2020-07-21T07:01:22+00:00 urn:sha1:51a79b1af7fa663bb078136611705c04df12970a coroutines don't have __next__; they also call themselves coroutines. This does not change the fact that `async def` methods are generators, but it does make them behave more like CPython. 2020-07-16T18:33:33+00:00 Dan Halbert halbert@adafruit.com 2020-07-16T18:33:33+00:00 urn:sha1:88d89563783771daba2973eb8dc3faa237ba4b62 Add support to json.load for any object with readinto 2020-07-11T00:33:17+00:00 Scott Shawcroft scott@tannewt.org 2020-07-11T00:33:17+00:00 urn:sha1:372bcf8a956c8b20c423333114d7aa061dd54751