can you treat sys as Dynamic object?

I don't understand the question! This is all in Python code, not C#.

@denfromufa I think you've missed the point somewhat. When passing a Python object to a managed call it is converted to a managed object (eg a python float is converted to a managed Double). If you were writing managed code you could use a dynamic type to refer to the instance of the converted object, but that doesn't help in this case as there is no conversion available from the python object to a managed object in the first place.

A possible solution would be to change Converter::ToManagedValue (in converter.cs) to fallback to convert all Python objects without a reasonable conversion to a native managed type to a PyObject managed type. This looks simple enough, but there are a couple of issues that would need to be considered:

• If the PyObject instance is cleaned up by the garbage collector it may block on acquiring the GIL and that may cause a deadlock as all other threads will be suspended (and one of those threads may have the GIL acquired).
• The Python object may end up being deleted by the Python garbage collector while the managed instance still exists if there are no other Python references left to the object. This would result in the object being dereferenced by the PyObject destructor after the CPython object had already been deallocated.

Both of these problems can be resolved, but I just wanted to point them out as it's not a simple as going in and fixing ToManagedValue.

@tonyroberts, @andygraham good point on Dynamic.

Regarding keeping PyObject in .NET, would that require pinning unmanaged Python object and later manually releasing the handle?
Not sure about similar mechanism on Python side.

Another thing I don't understand is why the following mechanism cannot be
reused when converting to managed - Python module can be imported in C#
side with Py.Import(), and its members dynamically accessed.

On Wed, Sep 2, 2015, 3:33 AM Tony Roberts notifications@github.com wrote:

@denfromufa https://github.com/denfromufa I think you've missed the
point somewhat. When passing a Python object to a managed call it is
converted to a managed object (eg a python float is converted to a managed
Double). If you were writing managed code you could use a dynamic type to
refer to the instance of the converted object, but that doesn't help in
this case as there is no conversion available from the python object to a
managed object in the first place.

A possible solution would be to change Converter::ToManagedValue (in
converter.cs) to fallback to convert all Python objects without a
reasonable conversion to a native managed type to a PyObject managed type.
This looks simple enough, but there are a couple of issues that would raise
that would need to be considered:

• If the PyObject instance is cleaned up by the garbage collector it
  may block on acquiring the GIL and that may cause a deadlock as all other
  threads will be suspended (and one of those threads may have the GIL
  acquired).
• The Python object may end up being deleted by the Python garbage
  collector while the managed instance still exists if there are no other
  Python references left to the object. This would result in the object being
  dereferenced by the PyObject destructor after the CPython object had
  already been deallocated.

Both of these problems can be resolved, but I just wanted to point them
out as it's not a simple as going in and fixing ToManagedValue.

—
Reply to this email directly or view it on GitHub
#94 (comment).

This is fixed.