.net abstract class usage with IronPython

Hi All,

I have a hypothetical/theoretical question:

Could anyone provide a script snippet showing how a .net abstract class is used in IronPython?
How do I use (override) its properties, methods, attributes?
Basically explaining this topic if possible in plain text.

Much obliged!

UPDATE:
Also getset_descriptors.
I always get TypeErrors when I try to use Abstract Class and getset_descriptors.

TypeError('Cannot create instances of SomeClass because it is abstract)
TypeError(‘getset_descriptor is not callable’,))
when I try SomeClass.__new__(OtherClass) I get TypeError(OtherClass does not define any public constructors)
etc.

Hi Ivelin,

here is an example with the abstract class of SpaceMorph.
I didn’t implement the Destructor (IDisposable), but its just for demonstration.

"""Provides a scripting component.
Inputs:
    x: The x script variable
    y: The y script variable
Output:
    a: The a output variable"""

__author__ = "tomj"

import rhinoscriptsyntax as rs


import Rhino 
from Rhino.Geometry import Vector3d,Point3d

class MyZMorpher(Rhino.Geometry.SpaceMorph):
  def __init__(self):
      Rhino.Geometry.SpaceMorph.__init__(self)
  def Morph(self,geom):
      geom.Translate(Vector3d(0,0,10))
  def MorphPoint(self,point):
      return Point3d(point.X,point.Y,-10)

"""
 public abstract Point3d MorphPoint(
	Point3d point)
"""

myMorpher = MyZMorpher()

if (isinstance(geom,Point3d)):
  print "its a point"
  geom = myMorpher.MorphPoint(geom)
else:
  print "its not a point"
  myMorpher.Morph(geom)

a = geom

exampleAbstractIronPython.gh (5.3 KB)

1 Like

Hi Tom,

Thanks for the example.

What does __init__(self) do, exactly? Is this like __new__() creating an instance?
In the api I don’t see neither __init__ nor __new__ is this an example of “extended method” for a class?

EDIT:
One additional question. I understand that when using from ASSEMBLY import * all the namespaces inside are imported as modules. and when using from ASSEMBLY import SOMETHING this SOMETHING is imported as a namespace. What is the difference when importing .net stuff which one is preferable.

See I am not giving solid examples because I’m not using currently Rhino/GH Apis, I’m using another software that I would like eventually to connect with Rhino/GH. And I’m having trouble navigating through that other API. On top of all that I’m trying COM interop link which makes it even harder to figure out what’s what. :slight_smile:

def __init__ (self) is the constructor of the class, whereas ParentClass.__init__(self) calls the constructor of the parent class. You can leave that out in this case , since an abstract class doesn’t do anything, its just a blue print.
Its just the basic way to derive in Python and IronPython 2.7

If you import everything from an module (import *) you can collide with names from other modules.
Depending on which module is loaded second, it will override the other. Better is “… import as …”
If you just need 2 classes, then you can directly import them with “from ASSEMBLY import SOMETHING”

Yeah, yeah, I know that.
What I was asking was the difference why are the namespaces imported as Modules when using import *
but when using from MODULE import NAMESPACE (that namespace is in fact .net dll)) then the namespace is imported as an actual namespace when you type(NAMESPACE) it.

My structure is i have a folder and I use it as a module, inside I have init.py and a bunch of other *.py that do clr.ReferenceFromFileAndPath(ALIEN.API.INTEROP.DLL)

This is just like C:\Users\peychev\AppData\Roaming\McNeel\Rhinoceros\6.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\ghpythonlib

I don’t know, In C# you can compose different .dll into one, application-wide Namespace.
For instance the myapp.exe contains MYAPP.APP, whereas myapp.core.dll contains MYAPP.CORE and MYAPP.UTILS namespace

Yeah I checked I don’t have nested Namespaces in these DLLs
only mscorelib.dll has a lot of nested ones, I import that one separately.

Both libraries can also share the exact same namespace. this is possible as well.

core1.dll can have Myapp.Core and core2.dll can also add in Myapp.Core.

Putting it together wouldn’t hint if its composed out of two dlls. Namespaces are just a way to organise your code, but has no technical meaning.

But as I said, I don’t know about this problem. I’m rather a fan of using C# for dot.net apps, and Python for Python.

How do you import both DLLs without causing a confusion when calling them then?

Can you clr.Ref both dlls then you say import (the namespace) and extract from both DLLs?

I think importing it in IronPython doesn’t mean to load the dll. It just says import anything from that namespace.

first you have to clr.Reference(the DLLs)
then you import the namespace, but if both dlls have the same namespace, could the methods inside collide?

Perhaps @piac can say more about this, as a person of both C# and IronPython(CPython) worlds. :slight_smile:

Me either

But this particular example is very unlikely, because it violates against good practice in multiple ways

I have such case, ALIEN.API.INTEROP.DLL and ALIEN.API.INTEROP.UPGRADE.DLL have both the same namespace inside, and the same classes/interfaces/methods, the second one has a bit more. Should I import both as separate modules inside python, or as mentioned above, clr.Ref both then use import namespace only once?

This is crazy :crazy_face:

I think both come from the same application, so concrete class definitions cannot be duplicated.

If you want the functionality ALIEN.API.INTEROP.UPGRADE.DLL just load it in as
import ALIEN.API.INTEROP.UPGRADE as aaiu

if you need the stuff from ALIEN.API.INTEROP.DLL just load in
import ALIEN.API.INTEROP as aai, but you cannot use ALIEN.API.INTEROP.UPGRADE.DLL objects if you are not loading in both. You can load in both as soons as they are part of the same application!

If they both coming from different apps then this is a problem, but its very unlikely.

is that what ApplicationCoClass and ApplicationCoClassClass means? :slight_smile: Concrete?

What does that mean?

That means someone has problems with naming classes. :rofl:

Example ALIEN.API.INTEROP.DLL has

ALIEN.API.INTEROP.Human
ALIEN.API.INTEROP.Zebra
ALIEN.API.INTEROP.Rhino

and ALIEN.API.INTEROP.UPGRADE.DLL has
ALIEN.API.INTEROP.UPGRADE.Dolphin
ALIEN.API.INTEROP.UPGRADE.Elefant

you can only use Human if you load ALIEN.API.INTEROP.DLL, and if you need a Dolphin you can load in both or just ALIEN.API.INTEROP.UPGRADE.DLL. Usually you load all assemblies.

If you just load ALIEN.API.INTEROP.UPGRADE.DLL, ALIEN.API.INTEROP has no Human,Zebra and Rhino in there. Its that easy

1 Like

I understand.

I’ll keep struggling. And create some Python classes of .net abstract classes as you showed me above.

Thanks a lot Tom.

1 Like

Tom:

What does such expression do in C#:

INFITF.Application MyAPP = (INFITF.Application)System.Runtime.InteropServices.Marshal.GetActiveObject("MyAPP.Application");

//

Mainly Why the Heck is INFITF.Application put in brackets?
If I do such thing in Python I get an error