Pavel Koneski

> Seems to work as you expect. Not exactly. After getting the lambda object from the call `List[Object]().FirstOrDefault(lambda x, y: True)`, subsequent calls with the "good" lambda return the lambda...

Thanks for the well-prepared report. I was able to reproduce the problem using the latest development version.

The underlying cause of this problem is that the conversion of an object (here an `OrderedDict`) to an enumerable (here, in the `list` constructor) happens in the default code context....

I [wrote about finalizers before](https://github.com/IronLanguages/ironpython3/pull/808#issuecomment-627002117), so here is just the bottom line: every time I see that finalizers are used as a mechanism for anything else than preventing unmanaged resource...

> example you designed is a circular reference and there's no ideal order of calling Yes, I was curious what CPython would do in such "impossible" scenario. It had basically...

Yes, I was able to reproduce the failure. The test crashes on `test_big_codesize` with a stack overflow. To be more specific, it crashes on the first `match` on the compiled...

Can this be closed now?

It looks to me that those documents were a test run / starting point / work in progress that never got fully adapted to IronPython. BTW, `termios` will be needed...

I think the concern about creating and populating a `HashSet` on every call is a valid one. Another idea: what if methods are being resolved in in a way that...

> Although now that I'm looking at `PythonExtensionBinder.GetMember` (the only consumer of `ExtensionMethodSet.GetExtensionMethods`) it's already allocating a `List`. This could easily be switched to a `HashSet` and this would eliminate...