@DfM7

Firstly,

Lets discuss the next snippet:

from PyNetFails import A
a = A()
print(type(a.V))

It really produces <class 'int'>, as it must be. But not the System.UInt32.
As said from pythonnet `documentation:

Type conversion under Python for .NET is fairly straightforward - most elemental Python types (string, int, long, etc.) convert automatically to compatible managed equivalents (String, Int32, etc.) and vice-versa.

You can read more information on official pythonnet documentatition. Take a look at paragraph Type conversion.

Secondly,

Lets take into account the first notice (result of a.V is converted from System.UInt32 directly to the Python type <class 'int'>) and take a look at the next Python code:

from System import UInt32
v = UInt32(42)
print(v >= a.V)

In the 3-rd line print(v >= a.V), as result of a.V is converted to the Python type, we are trying to compare CLR object v of type System.UInt32 with the Python object, which returned in a result of a.V. As a result of this comparision, we receive TypeError: Cannot get managed object.

So, this action fails, as pythonnet cannot compare Python objects with CLR and vice versa.
In this case, you can fix it, for example, by comparing CLR objects (requires add explicit cast to CLR object):

from System import UInt32
v = UInt32(42)
print(v >= UInt32(a.V))

or fix problem, by comparing Python objects:

v = 42
print(v >= a.V)

@denfromufa I am convinced it is not a bug. It is a documented behaviour.

@Konstantin-Posudevskiy yes, that's what I originally suggested to @DfM7. But I'm thinking that this is annoyance and unexpected behavior.

https://stackoverflow.com/questions/44491159

IMHO, the first step doesn't qualify as a bug, like @Konstantin-Posudevskiy said, it's documented (and sensible) behaviour. Regarding the comparison, I think we could add special cases for the conversion operators that detect mapped Python types and convert them back to their .NET counterpart.

Seems to be related with #94

@Konstantin-Posudevskiy
Thank you for your clarification.

I had read all of the paragraphs in the official documentation before I've posted the question on SO.
I've just interpreted the "Type Conversion" paragraph in another way, as I got that, for example, System.Int32 and int are logically equivalent, but not System.UInt32 and int.

originally reported here: https://stackoverflow.com/questions/44491159

As discussed above, this is not a bug.