GitLab

Needs proper coverage testing.  Doesn't implement -ve & -ve.
Addresses issue #611.

This means that complete slice operations are supported for lists (but not
for bytearray's and array.array's).

Caveat is that __new__ should recurse to base class __new__, and ultimately,
object.__new__ is what handles instance allocation.

Also, define object.__init__() (semantically empty, purely CPython compat
measure). Addresses #520.

Now case of subclassing tuple works, and list is broken, see comments.

This time, in mp_seq_cmp_bytes(). How many more cases are still lurking?

sep=None is TODO.

Addresses issue #610.

Infra for counts of other types is there, need last mile to be implemented.

On Mac OS "python3 test/basics/memoryerror.py" never runs out of memory, the process is frozen by the os before.

This is not fully correct re: error handling, because we should check that
that types are used consistently (only str's or only bytes), but magically
makes lot of functions support bytes.

Two things are handled here: allow to compare native subtypes of tuple,
e.g. namedtuple (TODO: should compare type too, currently compared
duck-typedly by content). Secondly, allow user sunclasses of tuples
(and its subtypes) be compared either. "Magic" I did previously in
objtype.c covers only one argument (lhs is many), so we're in trouble
when lhs is native type - there's no other option besides handling
rhs in special manner. Fortunately, this patch outlines approach with
fast path for native types.

This was hit when trying to make urlparse.py from stdlib run. Took
quite some time to debug.

TODO: Reconsile bound method creation process better, maybe callable is
to generic type to bind at all?

Slice value to assign can be only a list so far too.

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.