This PR adds support for the `__set_name__` data model method
specified by PEP487 - Simpler customisation of class creation.

This includes support for methods that mutate the owner class,
and avoids the naive modify-while-iterating hazard possible in a naive
implementation like micropython#15503.

Note that based on the benchmarks in micropython#16825, this
is also as fast or faster than the naive implementation, thanks to
clever data layout in setname_list_t, and the way this allows the
capture step to run during an existing loop through the class dict.

Other rejected approaches for dealing with the hazard include:

- python/cpython#72983
During the implementation of this feature for MicroPython, it was
discovered that some versions of CPython also have this naive hazard.
CPython resolved this bug in BPO-28797 and now makes a complete flat
copy of the class's dict to iterate. This design decision doesn't make
much sense for a microcontroller though, even if it's perfectly
reasonable in the desktop world where memcpy might actually be cheaper
than a hard-to-branch-predict conditional; and it's also motivated in
their case by error-tracing considerations.

- micropython#16816
This is an equivalent implementation to CPython's approach that places
this copy directly on the stack; however it is both slower and has
larger code size than the approach taken here.

- micropython#15503
The simplest implementation is to just not worry about it and let the
user face the consequences if they mutate the owner class.
That's not a very friendly behavior, though, and it's not actually much
more performant than this implementation on either time or code size.

- micropython#17693
Another alternative is to do the same as micropython#15503 but leverage
MicroPython's existing `is_fixed` field in its dict type to convert
attempted mutations of the owner dict into `AttributeError`s.
This is safer than just leaving the open hazard, but there's still
important use-cases for owner-mutating descriptors, and the performance
ain is small enough that it isn't worth missing support for those cases.

- combined micropython#17693 with this
Another version of this feature used a new feature define,
`MICROPY_PY_METACLASSES_LITE`, to control whether this algorithm or the
naive version is used. This was rejected in favor of simplicity, based
on the very limited performance margin the naive version has (which in
some cases even goes _against_ it).

Signed-off-by: Anson Mansfield <amansfield@mantaro.com>

This PR adds support for the `__set_name__` data model method
specified by PEP487 - Simpler customisation of class creation.

This includes support for methods that mutate the owner class,
and avoids the naive modify-while-iterating hazard possible in a naive
implementation like micropython#15503.

Note that based on the benchmarks in micropython#16825, this
is also as fast or faster than the naive implementation, thanks to
clever data layout in `setname_list_t`, and the way this allows the
capture step to run during an existing loop through the class dict.

Other rejected approaches for dealing with the hazard include:

- python/cpython#72983
During the implementation of this feature for MicroPython, it was
discovered that some versions of CPython also have this naive hazard.
CPython resolved this bug in BPO-28797 and now makes a complete flat
copy of the class's dict to iterate. This design decision doesn't make
much sense for a microcontroller though, even if it's perfectly
reasonable in the desktop world where memcpy might actually be cheaper
than a hard-to-branch-predict conditional; and it's also motivated in
their case by error-tracing considerations.

- micropython#16816
This is an equivalent implementation to CPython's approach that places
this copy directly on the stack; however it is both slower and has
larger code size than the approach taken here.

- micropython#15503
The simplest implementation is to just not worry about it and let the
user face the consequences if they mutate the owner class.
That's not a very friendly behavior, though, and it's not actually much
more performant than this implementation on either time or code size.

- micropython#17693
Another alternative is to do the same as micropython#15503 but leverage
MicroPython's existing `is_fixed` field in its dict type to convert
attempted mutations of the owner dict into `AttributeError`s.
This is safer than just leaving the open hazard, but there's still
important use-cases for owner-mutating descriptors, and the performance
ain is small enough that it isn't worth missing support for those cases.

- combined micropython#17693 with this
Another version of this feature used a new feature define,
`MICROPY_PY_METACLASSES_LITE`, to control whether this algorithm or the
naive version is used. This was rejected in favor of simplicity, based
on the very limited performance margin the naive version has (which in
some cases even goes _against_ it).

Signed-off-by: Anson Mansfield <amansfield@mantaro.com>

This PR adds support for the `__set_name__` data model method
specified by PEP487 - Simpler customisation of class creation.

This includes support for methods that mutate the owner class,
and avoids the naive modify-while-iterating hazard possible in a naive
implementation like micropython#15503.

Note that based on the benchmarks in micropython#16825, this
is also as fast or faster than the naive implementation, thanks to
clever data layout in `setname_list_t`, and the way this allows the
capture step to run during an existing loop through the class dict.

Other rejected approaches for dealing with the hazard include:

- python/cpython#72983
During the implementation of this feature for MicroPython, it was
discovered that some versions of CPython also have this naive hazard.
CPython resolved this bug in BPO-28797 and now makes a complete flat
copy of the class's dict to iterate. This design decision doesn't make
much sense for a microcontroller though, even if it's perfectly
reasonable in the desktop world where memcpy might actually be cheaper
than a hard-to-branch-predict conditional; and it's also motivated in
their case by error-tracing considerations.

- micropython#16816
This is an equivalent implementation to CPython's approach that places
this copy directly on the stack; however it is both slower and has
larger code size than the approach taken here.

- micropython#15503
The simplest implementation is to just not worry about it and let the
user face the consequences if they mutate the owner class.
That's not a very friendly behavior, though, and it's not actually much
more performant than this implementation on either time or code size.

- micropython#17693
Another alternative is to do the same as micropython#15503 but leverage
MicroPython's existing `is_fixed` field in its dict type to convert
attempted mutations of the owner dict into `AttributeError`s.
This is safer than just leaving the open hazard, but there's still
important use-cases for owner-mutating descriptors, and the performance
ain is small enough that it isn't worth missing support for those cases.

- combined micropython#17693 with this
Another version of this feature used a new feature define,
`MICROPY_PY_METACLASSES_LITE`, to control whether this algorithm or the
naive version is used. This was rejected in favor of simplicity, based
on the very limited performance margin the naive version has (which in
some cases even goes _against_ it).

Signed-off-by: Anson Mansfield <amansfield@mantaro.com>