← index #2628Issue #2092
Off-topic · high · value 0.584
QUERY · ISSUE

Extend obj->iternext to handle not just __next__(), but also send() method

openby pfalconopened 2016-11-13updated 2017-06-30
rfc

For generators (generalization of iterators), .__next__() method is defined as .send(None). It's only natural to extend C-level ->iternext() method to accept send argument, to allow implementation of C-level generators optimally. Caveat: so far, none of such exist. But work on optimizing uasyncio may lead to need for such. Or maybe not, maybe "virtual" awaitable methods will be used instead: https://github.com/micropython/micropython/issues/2622 .

This ticket is created to be referenced by in-code TODO comments (yes, I think we reached that code complexity that need to reference tickets straight from code).

CANDIDATE · ISSUE

RFC: Inheriting base class should copy "protocol" vtables to subclass

closedby pfalconopened 2016-05-20updated 2016-06-19
rfc

After long thinking how to approach issues like https://github.com/micropython/micropython/pull/2091#issuecomment-220724740 or subclassing stream classes in Python, I guess what we need is subj.

The idea (applied to Pin classes) would be: have unix modumachine implement PinBase class. It's Pin C-level pin protocol (which we again and again can't introduce and take adhoc hardware-specific shortcuts instead), would have implementation of looking up an calling Python-level methods. Then when Python code will inherit from such base class, "Pin" protocol vtable should be copied to it, so everything work as expected, as with minimal overhead to other classes.

Keyboard

j / / n
next pair
k / / p
previous pair
1 / / h
show query pane
2 / / l
show candidate pane
c
copy suggested comment
r
toggle reasoning
g i
go to index
?
show this help
esc
close overlays

press ? or esc to close

copied