slozier

Separate modules sounds fine as long as we can share the common code.

Yep, making it virtual makes the error go away. I stepped through the code and it looks like the two candidates are exactly as you suggest: > {MethodCandidate(System.Numerics.BigInteger write(IronPython.Runtime.CodeContext, System.Object)...

Made the write overload virtual in https://github.com/IronLanguages/ironpython3/pull/1071 to get the test passing. Should revisit once we decide how to resolve this.

Ran into this issue again (this time due to `readinto`) in `test_urllib`.

There's also code commented in https://github.com/IronLanguages/ironpython3/pull/1544 that should be enabled once we handle the syntax.

> On a wider note, the SQLite implementation that IronPython uses looks very old, unmaintained, supporting obsolete platforms, and not supporting the platforms that IronPython and .NET currently target. So...

Also https://github.com/IronLanguages/ironpython3/pull/1095 with more warnings for Thread.ResetAbort from .NET 6.

Revert https://github.com/IronLanguages/ironpython3/pull/169 hack once this is properly implemented.

It's an interesting idea. I have a local branch that targets 3.5 which works fairly well after commenting out the few async/await instances that appear in the standard library. I...

I don't know how much control we have over the permissions during NuGet package creation. Not finding much documentation on the matter.